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1 Introduction 


1.1 Objectives 


This document describes how the NFC Digital Protocol Specification can be used to set-up the 
communication protocol with the other device. 


This document describes the building blocks, called Activities, for setting up the communication 
protocol. 


These Activities can be used as defined in this specification or can be modified to define other 
ways of setting up the communication protocol, covering the same or different use cases. 


Activities are combined in Profiles. Each Profile has specific Configuration Parameters and 
covers a particular use case. 


This document covers corresponding Profiles for the NFC Forum use cases. 


1.2 Audience 


This document is intended for use by manufacturers wanting to implement an NFC Forum 
Device. 


1.3 Applicable Documents or References 


The following documents contain provisions that are referenced in this specification. The latest 
version including all published amendments applies unless a publication date is explicitly stated. 


[ANALOG] NFC Analog, 
In progress, 
NFC Forum 


[DIGITAL] NFC Digital Protocol, 
Version 1.0, 
NFC Forum 


[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, 
S. Bradner, 
March 1997, 
Internet Engineering Task Force 


[T1TOP] Type 1 Tag Operation Specification 
Version 1.0, 
NFC Forum 


[T2TOP] Type 2 Tag Operation, 
Version 1.0 
NFC Forum 

[T3TOP] Type 3 Tag Operation, 
Version 1.0, 
NFC Forum 

[TATOP] Type 4 Tag Operation, 


Version 2.0, 
NFC Forum 
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1.4 Administration 


The NFC Activity Specification is an open specification supported by the Near Field 
Communication Forum, Inc., located at: 


401 Edgewater Place, Suite 600 
Wakefield, MA, 01880 


Tel.: +1 781-876-8955 
Fax: +1 781-610-9864 


http://www.nfc-forum.org/ 


The NFC Devices Technical Working Group maintains this specification. 


1.5 Name and Logo Usage 


The Near Field Communication Forum’s policy regarding the use of the trademarks NFC Forum 
and the NFC Forum logo is as follows: 


e Any company MAY claim compatibility with NFC Forum specifications, whether a member 
of the NFC Forum or not. 


e Permission to use the NFC Forum logos is automatically granted to designated members only 
as stipulated on the most recent Membership Privileges document, during the period of time 
for which their membership dues are paid. 


e Member’s distributors and sales representatives MAY use the NFC Forum logo in promoting 
member's products sold under the name of the member. 


e The logo SHALL be printed in black or in color as illustrated on the Logo Page that is 
available from the NFC Forum at the address above. The aspect ratio of the logo SHALL be 
maintained, but the size MAY be varied. Nothing MAY be added to or deleted from the 
logos. 


e Since the NFC Forum name is a trademark of the Near Field Communication Forum, the 
following statement SHALL be included in all published literature and advertising material in 
which the name or logo appears: 


NEC Forum and the NFC Forum logo are trademarks of the Near Field Communication 
Forum. 


1.6 Intellectual Property 


The NFC Activity Specification conforms to the Intellectual Property guidelines specified in the 
NFC Forum' Intellectual Property Rights Policy, as outlined in the NFC Forum Rules of 
Procedure. 


1.7 Special Word Usage 


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, 
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL.” in this 
document are to be interpreted as described in [RFC2119]. 
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1.8 Requirement Numbering 


Requirements in this document are uniquely numbered with the number appearing next to each 
requirement. Requirements can include informative statements in the italic font and MAY instead 


of MUST is used. For example: 


Table 1: Sample Requirement 


1.8.1.1 A car MUST have four wheels. 
A car MAY have alloy wheels. 


A requirement can have different numbers in different versions of the specifications. Hence, all 
references to a requirement MUST include the version of the document as well as the 
requirement’s number. 


A figure that is labeled “flow chart” illustrates the behavior given by the corresponding 
requirements tables. Figures are informative if not otherwise stated. An example is show in 


Figure 1. 


yes 
Turn? Blink 
no | n+2 
Turn 
Stop blinking 
« 
v 
Continue 


Figure 1: Example Flow Chart 
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A requirement can be labeled as a symbol, when referring to a flow chart, indicating a particular 
sequence. If the current requirement is labeled “Symbol n”, then the next requirement in the 
sequence is “Symbol n+1”, unless explicitly stated differently. 


1.8.1.2 


1.8.1.3 


1.8.1.4 


1.8.1.5 


1.8.1.6 


Table 2: Example Requirements 


Symbol n 
If a car wants to turn to left or right, it MUST proceed to Symbol n+1. 
Otherwise, the car MUST proceed to Symbol n+4. 

Symbol n+1 

The car MUST blink. 

Symbol n+2 
The car MUST turn. 
Symbol n+3 
The car MUST stop blinking. 
Symbol n+4 


The car MUST continue to drive straight ahead or stop. 
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1.9 Notational Conventions 


1.9.1 Notations 


The notational conventions as defined in Table 3 apply to this document. 
Table 3: Notational Conventions 


Notation Description 


XYh Hexadecimal notation. 
Values expressed in hexadecimal form are followed by a lower case “h”. 
For example, 27509 decimal is expressed in hexadecimal as 6B75h. 


xyb Binary notation. 
Values expressed in binary form are followed by a lower case “b”. 
For example, 82h hexadecimal is expressed in binary as 10000010b. 


[...] Optional part 

XX More than one value possible 

STATE States are written in COURIER FONT and in bold to distinguish them from the 
text. 


PARAMETER | Parameters are written in Capital Letters to distinguish them from the text. 


CON _ Prefix for Configuration Parameters (e.g., CON DEVICES LIMIT). 
INT_ Prefix for variables used in the Activities (e.g., INT_COLL_PEND). 
GRE_ Prefix for variables used in the Greedy Collection (e.g., GRE_POLL_A). 
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1.9.2 Figures 


Table 4 defines the graphical notation used in the figures of this document. 


Table 4: Figure Notation 


Activity 
Activity 


Start of a flow chart 


Connection point with dedicated label as used when a flow chart is split 
into multiple figures 


Nena 


End of a flow chart 


Test block with one input branch and several output branches 


elementar 
action á Elementary action block 
processing Processing block that can be decomposed in elementary action blocks 
block and/or other processing blocks 
Connecting element with processing flow indicated by the direction of 
the arrow 


1.10 Abbreviations 


The abbreviations as used in this document are defined in Table 5. 
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Table 5: Abbreviations 


Description 


Application Family Identifier 


ALL_REQ 


ALL NFC-A REQuest 


ALLB_REQ (AFI, N1) 


ALL NFC-B REQuest with matching AFI and N equal to 1 


ALLB_REQ (AFI, N>) 


ALL NFC-B REQuest with matching AFI and N greater than 1 
and if R is greater than 1 


ALLB_REQ (nAFI) 


ALL NFC-B REQuest with not matching AFI 


ANTICOLL ANTICOLLision 

BITR BIT Rate 

BCC Byte Check Cln 

CLn Cascade Level n (1 € n € 3) 
CMD CoMmanD 

CUP Check Update Proprietary 
COLL COLLision 

DA Device Activation 

DD Device Deactivation 

DE Data Exchange 

DECL DECLared 

DEP REQ Data Exchange Protocol REQuest 
DSI Data rate Send by Initiator 
DSL DeSeLect 

Fc Carrier Frequency 

FDT Frame Delay Time 

FWT Frame Waiting Time 

GB General Bytes 

GT Guard Time 

ID Identifier 

ISO International Organization for Standardization 
LLCP Logical Link Control Protocol 
Max Maximum 

Min Minimum 

ms millisecond 

n.à not applicable 
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Description 


N Number of slots 
NDEF NFC Data Exchange Format 
NFC Near Field Communication 
NFC-A Near Field Communication — Type A Technology 
NFC-B Near Field Communication — Type B Technology 
NFC-F Near Field Communication — Type F Technology 
NDEF NFC Data Exchange Format 
NFCIDO NFC-B identifier. 
NFCIDO is always 4 bytes long. 
NFCID1 NFC-A identifier. 
NFCID1 can be 4, 7, or 10 bytes long (simple, double, or triple 
size). 
NFCID1 CLn Contains the portion of the NFCID1 relative to the cascade level 
NECIDI CLn is always 4 bytes long. 
NFCID2 NFC-F identifier 
NFCID2 is always 8 bytes long. 
NFCID3 NFC-DEP identifier 
NFCID3 is always 10 bytes long. 
P2P Peer 2 Peer 
RATS Request for Answer To Select 
PEND PENDing 
PDU Protocol Data Unit 
PSL_REQ (A) Parameter SeLection REQuest with DSI indicating NFC-A 
PSL_REQ (F) Parameter SeLection REQuest with DSI indicating NFC-F 
PTGT Proprietary Technology Guard Time 
R Randomly chosen slot number, NFC-B 
RD Request Data 
REQU REQUested 
RF Radio Frequency 
RLS ReLeaSe 
SC System Code, NFC-F 
SDD Single Device Detection 
SEL SELection 


SENSB_REQ (AFI, N1) 


SENS NFC-B REQuest with matching AFI and N equal to 1 
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Abbreviation Description 


SENSB_REQ (AFI, N>) SENS NFC-B REQuest with matching AFI and N greater than 1 
and if R is greater than 1 


SENSB REQ (nAFI) SENS NFC-B REQuest with not matching AFI 
SLEEP AF SLEEP NFC-A and NFC-F 

TECH TECHnology 

TID Initial Delay Time 

TRFW RF Waiting Time 


1.11 Glossary 


1.11.1 Field 
No Remote Field Sensed 


A condition of the Remote Field that indicates the absence of remote devices. For the 
definition, see [ANALOG]. 


Operating Field 
The radio frequency field created by the NFC Forum Device in Poll Mode. 
Operating Field Off 


A condition of the Operating Field when the field strength is below a well-defined 
threshold. For the definition, see [ANALOG]. 


Operating Field On 


A condition of the Operating Field when the field strength is above a well-defined 
threshold for a minimum period of time. For the definition, see [ANALOGI]. 


Remote Field 
The radio frequency field sensed by the NFC Forum Device in Listen Mode. 
Remote Field Present 


A condition of the Remote Field being stable and strong enough to put the NFC Forum 
Device in a state that it can operate in Passive Communication mode. For the definition, 
see [ANALOG]. 


Unmodulated Carrier 
A condition of the Operating Field with no modulation present. For the definition, see 
[ANALOG]. 

1.11.2 Technology and Communication 

Byte Sequence 


Concatenation of hexadecimal values. 


NFC Activity Specification Page 17 


Introduction 


Collision 
For NFC-A, a collision is a superposition of a ‘0’ and a ‘1’ as defined in [DIGITAL]. 


For NFC-B and NFC-F, a collision is a superposition of multiple Responses, resulting in 
a Transmission Error. 


Command 


An instruction from one device to another device in order to move the other device 
through a state machine. 


Correct Frame 

A frame without Transmission Error. 
ISO-DEP Protocol 

The half-duplex block transmission protocol as defined in [DIGITAL]. 
NFC-DEP Protocol 

The half-duplex block transmission protocol as defined in [DIGITAL]. 
Passive Communication 


A communication mode in which one device generates an Operating Field and sends 
Commands to a second device. To respond, this second device uses load modulation, 
which means that it does not generate an Operating Field but it draws power from a 
Remote Field. 


Poll Command 
A Command to probe an NFC Forum Device in Listen Mode or an NFC Forum Tag: 
e ALL REQ or SENS_REQ Command for NFC-A 
e ALLB REQ or SENSB REQ Command for NFC-B 
e SENSF REQ Command for NFC-F 
Proprietary Command 


Any Command from one of the NFC technologies of which the meaning is outside of the 
scope of this specification. This applies in particular to the Type 1 Tag Platform, to the 
Type 2 Tag Platform, and to the Type 3 Tag Platform. 


Proprietary Technology 


Any technology of which the Command(s) used in the Technology Detection Activity 
do(es) NOT move the NFC Forum Device (in Listen Mode) out of the IDLE state. 
Further specification of Proprietary Technologies is outside the scope of this document. 


Reader/Writer 


Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has 
gone through a number of Activities. In this mode, the NFC Forum Device behaves like a 
legacy contactless reader and uses Commands from one of the Technology Subsets. 


Response 


Information sent from one device to another device upon receipt of a Command. The 
information received by the other device should allow this other device to continue the 
data exchange. 
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Technology 


A group of transmission Parameters defined by the NFC standard that makes a complete 
communication protocol. A non-exhaustive list of transmission Parameters is: RF carrier, 
communication mode, bit rate, modulation scheme, bit-level coding, frame format, 
protocol, and Command set. NFC defines three groups and therefore three Technologies: 
NFC-A, NFC-B, and NFC-F. The three Technologies use the same RF carrier (13.56 
MHz). Each Technology uses its own modulation scheme, bit-level coding, and frame 
format, but may have the same protocol and Command set. 


Technology Subset 


A legacy platform supporting a subset of a Technology. A Technology Subset supports at 
least the Poll Command of the Technology. The four Technology Subsets described in 
this specification are: 


e Type 1 Tag Platform, which uses a particular subset of NFC-A, excluding anti- 
collision 


e Type 2 Tag Platform, which uses a particular subset of NFC-A, including anti- 
collision 


e Type 3 Tag Platform, which uses a particular subset of NFC-F 


e Type 4 Tag Platform, which uses a particular subset of NFC-A or NFC-B, including 
anti-collision 


Valid Block, Valid PDU 
A block or PDU without Protocol Error within a Correct Frame. 
Valid Command, Valid Response 


A Command or Response without Protocol Error within a Correct Frame. 


1.11.3 Device 
Card Emulator 


Role of an NFC Forum Device, reached when an NFC Forum Device in Listen Mode has 
gone through a number of states or sub-states and in which the NFC Forum Device 
behaves as one of the Technology Subsets. 


Initiator 


Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has 
gone through a number of Activities; in this mode the NFC Forum Device communicates 
using the NFC-DEP Protocol. 


Listen Mode 


Initial mode of an NFC Forum Device when it does not generate a carrier; in this mode, 
the NFC Forum Device listens for the Remote Field of another device. 


NFC Forum Device 


A device that supports the following Modus Operandi: Initiator, Target, and 
Reader/Writer. It may also support Card Emulator. 
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NFC Forum Tag 
A contactless tag or (smart) card supporting NDEF. 
NFCIDx 


The identifiers NFCIDO, NFCID1, NFCID2, and NFCID3 for NFC-B, NFC-A, NFC-F, 
and NFC-DEP respectively. Identifiers subsumed under the term NFCIDx always belong 
to the same Technology. 


Poll Mode 
Initial mode of an NFC Forum Device when it generates a carrier and polls for other 
devices. 
State 
A Technology-independent state of the NFC Forum Device in Listen Mode. 
Sub-state 
A state of the NFC Forum Device in Listen Mode, specific to a Technology or 
Technology Subset. 
Target 


Role of an NFC Forum Device, reached when the NFC Forum Device in Listen Mode has 
gone through a number of Activities in which the NFC Forum Device communicates 
using the NFC-DEP Protocol. 

1.11.4 Specific to This Specification 

Activity 
A process within an NFC Forum Device. 

Bail-out Option 


A configuration option that allows the NFC Forum Device to conclude the Technology 
Detection Activity, if the respective Bail-out parameter is set. 


Configuration Parameters 


Parameters that are determined before the first Activity of a Profile is performed. 
Configuration Parameters cannot be changed when performing the sequence of Activities 
belonging to a Profile. 


Greedy Collection 


Temporary storage for information collected as part of the Activity and used during 
processing. 


Poll Profile 
The Profile of an NFC Forum Device when in Poll Mode. 
Profile 


The combination of a Resolution Process managing a set of Activities, an Initialization 
that chooses a set of values as Configuration Parameters, and Clean-up. 
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Resolution Process 
The part of the adjacent upper layer managing the Activities. The Resolution Process 
decides the next Activity to perform and hands over the Parameters needed. 

1.11.5 Errors 

OTHER 


A Protocol Error, Timeout Error, or Transmission Error. Refer to Section 5 for the usage 
of OTHER. 


Protocol Error 

A Semantic Error or Syntax Error. 
Semantic Error 

A Correct Frame with no Syntax Error is received when it is not expected. 
Syntax Error 


A Correct Frame is received with invalid content. In this case, the coding of the 
Command or the block within the frame is not consistent with [DIGITAL]. 


Timeout Error 
No Response has been received within the Response Waiting Time. See [DIGITAL]. 
Transmission Error 


An incorrect frame is received. In this case, the signal modulation, the bit coding, the 
frame format, the timing, or the checksum is not consistent with [DIGITAL]. 
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2 Purpose 


The Activity Specification describes a layer complementary to the Digital Protocol Specification. 


This document lists the requirements of the behavior of an NFC Forum device as it can be 
observed from monitoring the radio frequency field. The specification should be read as such, 
focusing on the external behavior, even if the description may be interpreted as a software 
implementation specification. Any implementation that creates the same external behavior as 
specified—and that is therefore indistinguishable from a testing point of view—meets the 
requirements. 


It separately describes Listen Mode and Poll Mode. 


Listen Mode is described in sections 3 to 5. These sections are composed of: 


1. 


Generic requirements (see Section 3) 


These requirements must be observed to ensure interoperability between different NFC 
devices, and between NFC devices and existing contactless infrastructure, independent of the 
implementation in the NFC Forum Device. 


Configuration (see Section 4) 


This section defines the Configuration Parameters that are available to configure the Listen 
Mode State Machine. 


State Machine (see Section 5) 


This section contains the State Machine with a detailed description of all the states. 


Poll Mode is described in sections 6 to 10. Those sections are composed of: 


1. 


Generic requirements (see Section 6) 


These requirements must be observed to ensure interoperability between different NFC 
devices, and between NFC devices and existing contactless infrastructure, independent of the 
implementation in the NFC Forum Device. 


RF Collision Avoidance (see Section 7) 


This section describes the process to prevent two NFC Forum Devices in proximity from both 
generating an Operating Field. 


Activity and Profile Model (see Section 8) 


This section describes the model used to represent functional blocks, called Activities, and 
the dependencies and order between them, called Profiles. 


Activities (see Section 9) 


This section describes process flows and Configuration Parameters for the following building 
blocks: 


e Technology detection: detects whether there is another device to communicate with and, 
if so, what technologies it supports 


e Collision resolution: detects the presence of multiple devices and enumerates the 
different identifiers 
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e Device activation: activates a particular device to establish a communication 
e Data exchange: exchange of application data 


e Device deactivation: deactivates this device to end the communication and be able to 
potentially activate another device 


Each flow or combination of flows looks like library functions that a developer can call upon. 
While it is not the intention of the specification to define or prescribe APIs, the specification 
can be used for this purpose. The developer then has the choice to use the process flows and 
variables as defined in the specification or develop his own. 


5. Profiles (see Section 10) 


This section defines values for the Configuration Parameters that, when used in combination 
with the process flows defined above, cover the NFC Forum Communication use cases. 


The combination of Activities and Profiles define a predictable, deterministic behavior of the 
NFC Forum Device (for error-free operation). This does not limit NFC Forum Devices from 
implementing other building blocks or defining other Profiles for other use cases, in addition to 
the existing ones. 


Listen Mode and its State Machine are a mandatory part of an NFC Forum Device 
implementation (some parts of the state machine are optional). 


The NFC Forum Device must implement the generic requirements of the Poll Mode to be NFC 
Forum compliant. 


An implementation of the Activities is optional. 


If an implementation claims conformance to optional parts of the specification, all requirements 
must be implemented as specified. 


The Profiles defined within this document are informative; however, they are recommended. 


NOTE This specification does not define Profiles for testing, as testing is outside of the 
scope of this document. Nevertheless, NFC-Forum-related test documentation may 
use the concept of Profiles and the underlying processes as input for the definition of 
a device test application. 
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3 Listen Mode — Generic Requirements 


The following generic requirements apply to Listen Mode. 


Requirements 1: Listen Mode — Generic 


Listen Mode 

3.1.1.1 For entering the Listen Mode state machine, the Operating Field MUST be 
in the Operating Field Off state. 

3.1.1.2 If the NFC Forum Device in Listen Mode responds to a single Poll 
Command with a single Response, then the NFC Forum Device MUST 
maintain a single state machine. 

3.1.1.3 If the NFC Forum Device in Listen Mode responds to a single Poll 
Command with multiple Responses, then the NFC Forum Device MUST 
maintain the equivalent number of independent state machines (i.e. a state 
machine for each Response). 

3.1.1.4 The start state of the NFC Forum Device in Listen Mode is the 
NO_REMOTE_FIELD State. 

3.1.1.5 If No Remote Field Sensed and not in state N0_REMOTE_FIELD, the NFC 


Forum Device MUST conclude the state machine and therefore the Listen 
Mode within a delay not greater than tegi p. ofr. Refer to Appendix B for the 
value of trier p. orr- 
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4 Listen Mode — Configuration 


Configuration Parameters need to be set before the Listen Mode state machine can be started. 
They allow technology-dependent responses to be configured, and to enable and disable optional 
parts. The Configuration Parameters are listed in Table 6: 


Table 6: Listen Mode — Configuration Parameters 


Name Format Size Description 


CON_LISTEN_DEP_A | binary 1 bit Controls whether to listen for NFC-A 
Technology with NFC_DEP support or not. 
- 1b: Listen for NFC-A Technology with 
NFC-DEP support 
- Ob: Do not listen for NFC-A 
Technology with NFC_DEP support 


CON_LISTEN_DEP_F | binary 1 bit Controls whether to listen for NFC-F 
Technology with NFC_DEP support or not. 
- 1b: Listen for NFC-F Technology with 
NFC-DEP support 
- 0b: Do not listen for NFC-F 
Technology with NFC-DEP support 


CON_LISTEN_T3TP binary 1 bit Controls whether to listen for NFC-F 
Technology with Type 3 Tag Platform 
support or not. 

- 1b: Listen for NFC-F Technology with 
Type 3 Tag Platform support 

- 0b: Do not listen for NFC-F 
Technology with Type 3 Tag Platform 
support 


CON LISTEN TA4ATP | binary 1 bit Controls whether to listen for NFC-A 
Technology with Type 4 Tag Platform 
support or not. 

- 1b: Listen for NFC-A Technology with 
Type 4 Tag Platform support 

- Ob: Do not listen for NFC-A 
Technology with Type 4 Tag Platform 
support 
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CON_LISTEN_T4BTP | binary 


Size 


1 bit 


Listen Mode — Configuration 


Description 


Controls whether to listen for NFC-B 

Technology with Type 4 Tag Platform 

support or not. 

- 1b: Listen for NFC-B Technology with 
Type 4 Tag Platform support 

- Ob: Do not listen for NFC-B 
Technology with Type 4 Tag Platform 
support 


CON ADV FEAT binary 


1 bit 


Controls the use of advanced protocol 
features. 


- 1b: Support advanced protocol features 


- Ob: Do not support advanced protocol 
features 


CON SYS CODE[N] | Array of 
Byte 


Sequences 


variable 


If configured for Type 3 Tag Platform, an 
ordered list of N system codes maintained 
by the adjacent upper layer (N70). 
Otherwise, the list contains a single system 
code of value FFFFh as a default value 
(N71). 


CON SENSF RES Array of 
Byte 


Sequences 


variable 


See SENSF RES format in [DIGITAL]. 

In particular: 

-  NFCID2 must be configured if the 
NFC Forum Device cannot generate 
random numbers 

- If configured for Type 3 Tag Platform, 
then PAD1, MRTIcuzgck, MRTluppate, 
PAD2, and RD must be configured as 
per [DIGITAL]. 

- Otherwise, these data elements can 
have any value. 


CON_ATR_RES Array of 
Byte 


Sequences 


variable 


See ATR_RES Format in [DIGITAL]. 

In particular: 

-  NFCID3; must be configured if the 
NFC Forum Device cannot generate 
random numbers 

- BS,, BR;, TO, PP;need to be 
configured 

- General bytes (G40...G4n) need to be 
configured if the upper adjacent layer 
wants to indicate some information 
such as LLCP support. 
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Name Format Size Description 

CON_ATS Array of variable See ATS format in [DIGITAL] 
Byte 
Sequences 

CON_SENSB_RES Array of variable See SENSB_RES format in [DIGITAL] 
Byte 
Sequences 

CON_ATTRIB_RES Array of variable See ATTRIB Response in [DIGITAL], in 
Byte particular MBLI 
Sequences 

CON_BITR_F integer 1 Byte At least one bit of these must be set: 


- b2=1: 212 kbps 
-  b3-1: 424 kbps 


NOTE 


NOTE 


NOTE 


If the NFC Forum Device in Listen Mode responds to a single Poll Command with 
multiple Responses, then the NFC Forum Device should foresee Configuration 
Parameters for each Response and criteria for deciding which subset of Responses to 
send, if all Responses cannot be sent. 


For NFC-B and NFC-F, when sending multiple Responses, the NFC Forum Device 
in Listen Mode should send a single Response within a single timeslot. 


If the NFC Forum Device in Listen Mode is configured to support 
CON_LISTEN_DEP_F and CON_LISTEN_T3TP, it must implement two 
independent state machines, according to Requirement 3.1.1.3. 
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5 Listen Mode — State Machine 


Table 7 defines the Listen Mode state machine of the NFC Forum Device. It includes all possible 
state transitions caused by Commands specified in [DIGITAL] for the functionality that is either 
mandatory (e.g., Target) or optional (e.g., Card Emulator). 


NOTE The behavior of Type 1 Tag and Type 2 Tag Commands are out of scope of this 
specification and are therefore not included in this state machine. 
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Table 7: Listen Mode — State Machine 
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Ą $ 5 B a | & A 3 s S É B & B a|BE|5]|s |8S | & & E E S 
\ E 4 a m m > 4 a m m > m 
z a E E E >. | o E ey Ę 5 E z Ę i o E E E 5 S E 
kj = z S z e kj x kj S kj a m | i z) < | | 
z ] i : m 4 m > [ \ [ | m 4 m > | I w m 
O > x z > B | ES = R > > = 5 e E m a ka z 
= |” S i : i ü E E E S 
le ka > | > © [el » 
E 3 3 c 2 3 
End State E E: E: E: 
[=] * ko 5 
NO REMOTE FIELD  |OTHER 
SENSB |SENSB 
IDLE ^ - 
Remote OTHER OTHER RLS [RLS RLS_ |RLS aj cab ALLB_ 
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EQ (A), OTHER (A) 
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B 
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READY_F SENSF_ SENSF 
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ATR_READY_F REQ OTHER 
TARGET F Roa 
PSL_ oe DEP_ 
D REQ |GrriER 
Œ), 
OTHER 
CARD_EMULATOR_3 CUP CUP OTHER |CUP 
DSL [DSL DSL_ |DSL 
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= REQ [REQ REQ [REQ OTHER 
SENSB_ SENSB_ 
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, ALLB_ OTHER | ALLB_ AFL N> 
REQ REQ ) 
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REQ N1) : ) 
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! Except for Valid Type 1 Tag Commands. The NFC Forum Device does not change state if it implements Type 1 Tag and received 
? Except for Valid Type 2 Tag Commands. The NFC Forum Device does not change state if it implements Type 2 Tag and received 


? The SEL_REQ CL1 applies for this state change only when the N 
* The SEL_REQ CL2 applies for this state change only when the N; 
5 The SEL_REQ CL1 applies for this state change only when the N 
5 The SEL_REQ CL2 applies for this state change only when the N; 
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FC Forum Device in Listen Mode uses a double- or triple-size N. 
FC Forum Device in Listen Mode uses a triple-size NFCID1. 
FC Forum Device in Listen Mode uses a single-size NFCID1. 


FC Forum Device in Listen Mode uses a double-size NFCID1. 


a Valid Type 1 Tag Command. 
a Valid Type 2 Tag Command. 
FCID1. 
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51 NO REMOTE FIELD State 


The requirements in this section apply to the NO REMOTE FIELD State. 


Requirements 2: Listen Mode - NO REMOTE FIELD State 
Listen Mode 


5.1.1.1 In the NO REMOTE FIELD State, if Remote Field Present, then the NFC Forum 
Device MUST enter the IDLE State within the Guard Times as defined in 
[DIGITAL]. 


Otherwise, the NFC Forum Device MAY conclude the Listen Mode. 


5.2 IDLE State 


The requirements in this section apply to the IDLE State. In this State, the NFC Forum Device is 
ready to receive Poll Commands for the Technologies it is configured for. 


Requirements 3: Listen Mode — IDLE State 
Listen Mode 


5.2.1.1 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, the NFC Forum Device 
MUST enter the READY_A Sub-state after it has received a Valid ALL_REQ 
Command and has transmitted its SENS_RES. 


5.2.1.2 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, the NFC Forum Device 
MUST enter the READY. A Sub-state after it has received a Valid SENS REQ 
Command and has transmitted its SENS_RES. 


5.2.1.3 If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the 
READY B DECL Sub-state after it has received a Valid SENSB REQ Command that 
contains an N equal to 1, an AFI that matches its own AFI. and after it has 
transmitted its SENSB RES. 


5.2.1.4 If CON LISTEN TA4BTP =1, the NFC Forum Device MUST enter the 
READY B DECL Sub-state after it has received a Valid ALLB_ REQ Command that 
contains an N equal to 1, an AFI that matches its own AFI, and after it has 
transmitted its SENSB RES. 


5.2.1.5 If CON LISTEN TA4BTP =1, the NFC Forum Device MUST enter the 
READY B DECL Sub-state after it has received a Valid SENSB. REQ Command that 
contains an N greater than 1, an AFI that matches its own AFI, its R is 1, and after it 
has transmitted its SENSB RES. 


5.2.1.6 If CON LISTEN TA4BTP =1, the NFC Forum Device MUST enter the 
READY B DECL Sub-state after it has received a Valid ALLB_ REQ Command that 
contains an N greater than 1, an AFI that matches its own AFI, its R is 1, and after it 
has transmitted its SENSB. RES. 
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Listen Mode 


5.2.1.7 


5.2.1.8 


5.2.1.9 


If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the 
READY_B_REQU Sub-state and it MUST NOT send a Response after it has received 
a Valid SENSB_REQ Command that contains an N greater than 1, an AFI that 
matched its own AFI, and its R is greater than 1. 


If CON_LISTEN_T4BTP =1, the NFC Forum Device MUST enter the 
READY_B_REQU Sub-state MUST NOT send a Response after it has received a 
Valid ALLB_REQ Command that contains an N greater than 1, an AFI that matches 
its own AFI, and its R is greater than 1. 


If CON_LISTEN_T3TP=1 and the NFC Forum Device in Listen Mode has received 
a Valid CHECK or UPDATE Command as defined in [T3TOP], the NFC Forum 
Device MUST send its Response and it MUST enter the CARD_EMULATOR_3 Sub- 
state. 


If CON_LISTEN_T3TP=1, the NFC Forum Device in Listen Mode MAY enter the 
CARD_EMULATOR_3 Sub-state after it has received a Proprietary Command. 


5.2.1.10 


5.2.1.11 


If CON_LISTEN_DEP_F=1 or CON_LISTEN_T3TP =1 and the NFC Forum 
Device in Listen Mode has received a Valid SENSF_REQ Command with one of 
the bit rates as indicated in CON_BITR_F, the NFC Forum Device MUST compare 
the value of SC in the SENSF_REQ sequentially with the system code values 
contained in CON_SYS_CODE. If the values correspond according to the 
conditions defined below, the NFC Forum Device in Listen Mode MUST stop the 
comparison and it MUST enter the READY_F Sub-state after it has transmitted its 
SENSF_RES, including CON_SENS_RES Response using the same bit rate of the 
received SENSF_REQ Command. 


An SC value in SENSF_REQ corresponds to the value contained in 
CON_SYS_CODE at index X: 


e If the value of SC in the SENSF_REQ Command is equal to FFFFh, or 


e If the value of SC in the SENSF_REQ is equal to the value of 
CON_SYS_CODE[X], or 


e Ifthe first byte of SC in the SENSF REQ Command has a value of FFh and the 
value of the second byte equals the value of the second byte of 
CON_SYS_CODE[X], or 


e If the second byte of SC in the SENSF_REQ Command has a value of FFh and 
the value of the first byte equals the value of the first byte of the 
CON_SYS_CODE[X] 


If the NFC Forum Device intends to include the RD bytes in the SENSF_RES 
according to the requirements given in [DIGITAL], the value of the RD bytes must 
be equal to the matching CON_SYS_CODE value. 


If OTHER as defined in Table 7, the NFC Forum Device MUST NOT send a 
Response and it MUST stay in the IDLE State. 


An NFC Forum Device MAY respond to Valid Type 1 Tag Commands and it MAY change state 
accordingly. 
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READY A Sub-state and READY A* Sub-state 


The requirements in this section apply to the READY A and READY A* Sub-states. In these states, 
the NFC Forum Device expects an SDD REQ Command to retrieve the complete NFCID1. 


Requirements 4: Listen Mode - READY A SUB-STATE and READY A* Sub-state 


Listen Mode 


5.3.1.1 


5.3.1.2 


5.3.1.3 


5.3.1.4 


5.4 


Upon receipt of a Valid SDD_REQ CL1 Command, the NFC Forum Device MUST 
send its NFCID1 CL1 and stay in the READY A (READY A*) Sub-state. 


Upon receipt of a Valid SEL REQ CL1 Command with a matching NFCID1 CL 1, 
an NFC Forum Device with a single-size NFCID1 MUST send its SEL. RES 
Response and it MUST enter the ACTIVE A (ACTIVE A*) Sub-state when it is 
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its 
SEL RES Response that the NFCID1 is complete. 


Upon receipt of a Valid SEL REQ CL1 Command with a matching NFCID1 CL 1, 
an NFC Forum Device with a double- or triple-size NFCID1 MUST send its 
SEL RES Response and it MUST enter the READY A' (READY A' *) Sub-state. 


If OTHER, the NFC Forum Device MUST NOT send a Response. 


When in the READY A Sub-state, the NFC Forum Device MUST return to the IDLE 
State. 


When in the READY  A* Sub-state, the NFC Forum Device MUST return to the 
SLEEP A Sub-state. 


READY _ A’ Sub-state and READY A"* Sub-state 


The requirements in this section apply to the READY A' and READY A" * Sub-states. The 
READY A' and READY A' * Sub-states are intermediate states that only exist for NFC Forum 
Devices with double- and triple-size NFCID1. In these states, the cascade level 1 of the NFCID1 
has been selected. 
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Requirements 5: Listen Mode - READY A'SUB-STATE and READY A'* Sub-state 


Listen Mode 


5.4.1.1 


5.4.1.2 


5.4.1.3 


5.4.1.4 


5.5 


Upon receipt of a Valid SDD_REQ CL2 Command, an NFC Forum Device MUST 
send its NFCID1 CL2 and stay in the READY A' (READY A" *) Sub-state. 


Upon receipt of a Valid SEL REQ CL2 Command with a matching NFCID1 CL2, 
an NFC Forum Device with a double-size NFCID1 MUST send its SEL. RES 
Response and it MUST enter the ACTIVE A (ACTIVE A*) Sub-state when it is 
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its 
SEL RES Response that the NFCID1 is complete. 


Upon receipt of a Valid SEL REQ CL2 Command with a matching NFCID1 CL2, 
an NFC Forum Device with a triple-size NFCID1 MUST send its SEL. RES 
Response and it MUST enter the READY A" (READY A"*)Sub-state. 


If OTHER, the NFC Forum Device MUST NOT send a Response. 


When in the READY A' Sub-state, the NFC Forum Device MUST return to the 
IDLE State. 


When in the READY A' * Sub-state, the NFC Forum Device MUST return to the 
SLEEP A Sub-state. 


READY A" Sub-state and READY A"* Sub-state 


The requirements in this section apply to the READY A" and READY A"* Sub-states. The 
READY A" and READY A"* Sub-states are intermediate states that only exist for NFC Forum 
Devices with triple-size NFCID1. In these states, the cascade level 1 and 2 of the NFCID1 have 
been selected. 


Requirements 6: Listen Mode - READY A" SUB-STATE and READY A'"* Sub-state 


Listen Mode 


5.5.1.1 


5.5.1.2 


5.5.1.3 


Upon receipt of a Valid SDD_REQ CL3 Command, an NFC Forum Device MUST 
send its NFCID1 CL3 and stay in the READY A" (READY A"*) Sub-state. 


Upon receipt of a Valid SEL. REQ CL3 Command with a matching NFCID1 CL3, 
an NFC Forum Device with a triple-size NFCID1 MUST send its SEL. RES 
Response and it MUST enter the ACTIVE A (ACTIVE*) Sub-state when it is 
selected with its complete NFCID1. The NFC Forum Device MUST indicate in its 
SEL RES Response that the NFCID1 is complete. 


If OTHER, the NFC Forum Device MUST NOT send a Response. 


When in the READY A" Sub-state, the NFC Forum Device MUST return to the 
IDLE State. 


When in the READY  A"* Sub-state, the NFC Forum Device MUST return to the 
SLEEP A Sub-state. 
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5.6 — ACTIVE A Sub-state and ACTIVE A* Sub-state 
The requirements in this section apply to the ACTIVE A and ACTIVE A* Sub-states. In these 
states, the NFC Forum Device expects Commands for protocol activation. 


Requirements 7: Listen Mode - ACTIVE A SUB-STATE and ACTIVE A* Sub-state 
Listen Mode 


5.6.1.1 Upon receipt of a Valid SLP. REQ Command, the NFC Forum Device MUST enter 
the SLEEP A Sub-state. 


5.6.1.2 Upon receipt of a Valid ATR. REQ Command, the NFC Forum Device MUST send 
its ATR, RES Response and it MUST enter the ATR. READY A Sub-state. 


5.6.1.3 If CON LISTEN TAATP =1, the NFC Forum Device MUST send its ATS 
Response and it MUST enter the CARD EMULATOR 4A Sub-state after it has 
received a Valid RATS Command,. 


5.6.1.4 If OTHER as defined in Table 7, the NFC Forum Device MUST NOT send a 
Response. 


When in the ACTIVE A Sub-state, the NFC Forum Device MUST return to the 
IDLE State. 


When in the ACTIVE A* Sub-state, the NFC Forum Device MUST return to the 
SLEEP A Sub-state. 


An NFC Forum Device MAY respond to Valid Type 2 Tag Commands and it MAY change state 
accordingly. 


5.7 SLEEP A Sub-state 


The requirements in this section apply to the SLEEP A Sub-state. In this state, the NFC Forum 
Device only responds to an ALL. REQ Command. 


Requirements 8: Listen Mode - SLEEP A Sub-state 
Listen Mode 


5.7.1.1 Upon receipt of a Valid ALL. REQ Command, the NFC Forum Device MUST send 
its SENS RES Response and it MUST enter the READY. A* Sub-state. 


5.7.1.2 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the SLEEP. A Sub-state. 


5.8  ATR READY A Sub-state 


The requirements in this section apply to the ATR READY A Sub-state. In this state, the NFC 
Forum Device expects a PSL_REQ or a DEP. REQ Command. 
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Requirements 9: Listen Mode - ATR READY A Sub-state 


Listen Mode 


5.8.1.1 


Upon receipt of a Valid DEP. REQ Command, the NFC Forum Device MUST send 


5.8.1.2 


its DEP. RES Response and it MUST enter the TARGET A Sub-state. 


Upon receipt of a Valid PSL_REQ Command with DSI set to 000b, the NFC Forum 


5.8.1.3 


Device MUST send its PSL. RES Response and it MUST enter the TARGET. A Sub- 
state. 


Refer to [DIGITAL] for details on DSI coding. 


Upon receipt of a Valid PSL_REQ Command with DSI set to 001b or 010b, the 


5.8.1.4 


5.8.1.5 


5.8.1.6 


NFC Forum Device MUST send its PSL. RES Response and it MUST enter the 
TARGET. F Sub-state. 


Refer to [DIGITAL] for details on DSI coding. 


Upon receipt of a Valid DSL, REQ Command, the NFC Forum Device MUST send 
its DSL. RES Response and it MUST enter the SLEEP AF Sub-state. 


Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send 
its RLS. RES Response and it MUST enter the IDLE State. 


If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 


in the TARGET. A Sub-state. 


5.9 


TARGET A Sub-state 


The requirements in this section apply to the TARGET A Sub-state. In this state, the NFC Forum 
Device expects higher layer messages. 


Requirements 10: Listen Mode - TARGET A Sub-state 


Listen Mode 

5.9.1.1 Upon receipt of a Valid DEP. REQ Command, the NFC Forum Device MUST send 
its DEP. RES Response and stay in the TARGET. A Sub-state. 

5.9.1.2 Upon receipt of a Valid DSL, REQ Command, the NFC Forum Device MUST send 
its DSL, RES Response and it MUST enter the SLEEP AF Sub-state. 

5.9.1.3 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send 
its RLS_RES Response and it MUST enter the IDLE State. 

5.9.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 


in the TARGET_A Sub-state. 
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5.10 CARD EMULATOR 4A Sub-state 


The requirements in this section apply to the CARD_EMULATOR_4A Sub-state. In this state, the 
NFC Forum Device expects higher layer messages or an S(DESELECT) Request (see 
[DIGITAL]). 


Requirements 11: Listen Mode - CARD_EMULATOR_4A Sub-state 


Listen Mode 


5.10.1.1 Upon receipt of a Valid S(DESELECT) Request (as defined in [DIGITAL ]), the 
NFC Forum Device MUST send its SSDESELECT) Response and it MUST enter 
the SLEEP_A Sub-state. 


5.10.1.2 Upon receipt of a Valid Command in compliance with the Type 4A Tag Platform as 
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it 
MUST stay in the CARD_EMULATOR_4A Sub-state. 


5.10.1.3 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the CARD_EMULATOR_4A Sub-state. 
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5.11 READY_B_REQU Sub-state 


The requirements in this section apply when the NFC Forum Device is in the READY_B_REQU 
Sub-state. In this state, the NFC Forum Device expects an ALLB_REQ, a SENSB_REQ, or a 
corresponding SLOT_MARKER Command. 


Requirements 12: Listen Mode - READY B REQU Sub-state 


Listen Mode 


5.11.1.1 


5.11.1.2 


5.11.1.3 


5.11.1.4 


5.11.1.5 


5.11.1.6 


5.11.1.7 


5.11.1.8 


5.11.1.9 


5.11.1.10 


Upon receipt of a Valid SENSB REQ Command that contains an N equal to 1 and 
an AFI that matches its own AFI, the NFC Forum Device MUST send its 
SENSB RES and it MUST enter the READY B. DECL Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an N equal to 1 and an 
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB RES 
and it MUST enter the READY B  DECL Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send 
its SENSB RES and it MUST enter the READY B DECL. 


Upon receipt of a Valid ALLB. REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send 
its SENSB RES and it MUST enter the READY B. DECL Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device 
MUST NOT send a Response and it MUST stay in the READY B. REQU Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device 
MUST NOT send a Response and it MUST stay in the READY B REQU Sub-state. 


Upon receipt of a Valid SLOT MARKER Command indicating a Slot number 
matching R (as calculated at the reception of the last SENSB_REQ or ALLB_REQ), 
the NFC Forum Device MUST send its SENSB_RES and it MUST enter the 
READY_B_DECL Sub-state. 


Upon receipt of a Valid SENSB_REQ Command that contains an AFI that does not 
match its own AFI, the NFC Forum Device MUST NOT send its SENSB_RES and 
it MUST enter the IDLE Sub-state. 


Upon receipt of a Valid ALLB_REQ Command that contains an AFI that does not 
match its own AFI, the NFC Forum Device MUST NOT send a Response and it 
MUST enter the IDLE Sub-state. 


If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the READY_B_REQU Sub-state. 
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5.12 READY_B_DECL Sub-state 


The requirements in this section apply when the NFC Forum Device is in the READY_B_DECL 
Sub-state. In this state, the NFC Forum Device expects an ATTRIB or a SLPB_REQ Command. 


Requirements 13: Listen Mode - READY B DECL Sub-state 


Listen Mode 


5.12.1.1 


5.12.1.2 


5.12.1.3 


5.12.1.4 


5.12.1.5 


5.12.1.6 


5.12.1.7 


5.12.1.8 


5.12.1.9 


5.12.1.10 


5.12.1.11 


Upon receipt of a Valid ATTRIB Command, the NFC Forum Device MUST send 
its ATTRIB Response and it MUST enter the CARD EMULATOR 4B Sub-state. 


Upon receipt of a Valid SLPB. REQ Command, the NFC Forum Device MUST 
send its SLPB RES and it MUST enter the SLEEP. B Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an N equal to 1 and 
an AFI that matches its own AFI, the NFC Forum Device MUST send its 
SENSB RES and it MUST stay in the READY B DECL Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an N equal to 1 and an 
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB RES 
and it MUST stay in the READY B DECL Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send 
its SENSB RES and it MUST stay in the READY B DECL Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send 
its SENSB RES and it MUST stay in the READY B DECL Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device 
MUST NOT send a Response and it MUST enter the READY B. REQU Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device 
MUST NOT send a Response and it MUST enter the READY B. REQU Sub-state. 


Upon receipt of a Valid SENSB REQ Command that contains an AFI that does not 
match its own AFI, the NFC Forum Device MUST NOT send a Response and it 
MUST enter the IDLE Sub-state. 


Upon receipt of a Valid ALLB. REQ Command that contains an AFI that does not 
match its own AFI, the NFC Forum Device MUST NOT send a Response and it 
MUST enter the IDLE Sub-state. 


If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the READY B DECL Sub-state. 
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5.13 SLEEP B Sub-state 


The requirements in this section apply when the NFC Forum Device is in the SLEEP_B Sub-state. 
In this state, the NFC Forum Device expects an ALLB_REQ Command. 


Requirements 14: Listen Mode — SLEEP_B Sub-state 
Listen Mode 


5.13.1.1 Upon receipt of a Valid ALLB_REQ Command that contains an N equal to 1 and an 
AFI that matches its own AFI, the NFC Forum Device MUST send its SENSB_RES 
and it MUST enter the READY_B_DECL Sub-state. 


5.13.1.2 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is 1, the NFC Forum Device MUST send 
its SENSB_RES and it MUST enter the READY_B_DECL Sub-state. 


5.13.1.3 Upon receipt of a Valid ALLB_REQ Command that contains an N greater than 1, 
an AFI that matches its own AFI, and its R is greater than 1, the NFC Forum Device 
MUST NOT send a Response and it MUST enter the READY B. REQU Sub-state. 


5.13.1.4 Upon receipt of a Valid ALLB_REQ Command that contains an AFI that does not 
match its own AFI, the NFC Forum Device MUST NOT send a Response and it 
MUST enter the IDLE Sub-state. 


5.13.1.5 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the SLEEP_B Sub-state. 


5.14 CARD_EMULATOR_4B Sub-state 


The requirements in this section apply when the NFC Forum Device is in the 
CARD_EMULATOR_4B Sub-state. In this state, the NFC Forum Device expects higher layer 
messages or an S(DESELECT) Request (see [DIGITAL]). 


Requirements 15: Listen Mode - CARD_EMULATOR_4B Sub-state 
Listen Mode 


5.14.1.1 Upon receipt of a Valid S(DESELECT) Request (as defined in [DIGITAL ]), the 
NFC Forum Device MUST send its SSDESELECT) Response and it MUST enter 
the SLEEP B Sub-state. 


5.14.1.2 Upon receipt of a Valid Command in compliance with the Type 4B Tag Platform as 
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it 
MUST stay in the CARD EMULATOR 4B Sub-state. 


5.14.1.3 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the CARD EMULATOR 4B Sub-state. 


NFC Activity Specification Page 40 


Listen Mode — State Machine 


5.15 READY F Sub-state 


The requirements in this section apply to the READY_F Sub-state. In this state, the NFC Forum 
Device expects an ATR_REQ, a POLLING, a CHECK, or an UPDATE Command. 


Requirements 16: Listen Mode - READY_F Sub-state 


Listen Mode 


5.15.1.1 | Upon receipt of a Valid ATR. REQ Command, the NFC Forum Device MUST send 
its ATR, RES Response and it MUST enter the ATR READY F Sub-state. 


5.15.1.2 Upon receipt of a Valid CHECK or UPDATE Command as referred to in 
[DIGITAL] and defined in [T3TOP], the NFC Forum Device MUST send its 
Response and MUST enter the CARD EMULATOR 3 Sub-state. 


5.15.1.3 Upon receipt of a Valid SENSF REQ Command, the NFC Forum Device MUST 
compare the value of SC in the SENSF REQ sequentially with the system code 
values contained in CON SYS CODE. If the values correspond according to the 
conditions defined below, the NFC Forum Device in Listen Mode MUST stop the 
comparison, it must send its Response, and it MUST stay in the READY F Sub-state. 


An SC value in SENSF_REQ corresponds to the value contained in 
CON SYS CODE at index X: 


e If the value of SC in the SENSF REQ Command is equal to FFFFh, or 


e If the value of SC in the SENSF_REQ is equal to the value of 
CON SYS CODE[XI], or 


e Ifthe first byte of SC in the SENSF REQ Command has a value of FFh and the 
value of the second byte equals the value of the second byte of 
CON SYS CODEIX], or 


e If the second byte of SC in the SENSF REQ Command has a value of FFh and 
the value of the first byte equals the value of the first byte of the 
CON SYS CODE[X] 


If the NFC Forum Device will include the RD bytes in the SENSF RES according 
to the requirements given in [DIGITAL], the value of the RD bytes must be equal to 
the matching CON. SYS. CODE value. 


5.15.1.4 If OTHER, except for Proprietary Commands, the NFC Forum Device MUST NOT 
send a Response and it MUST stay in the READY F Sub-state. 


Upon receipt of a Proprietary Command, the NFC Forum Device MAY enter the 
CARD EMULATOR 3 Sub-state. 


NOTE The READY F state is known as MODE 0 in other, non-NFC-Forum specifications 
(e.g., JIS X 6319-4). 
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5.16 ATR READY F Sub-state 
The requirements in this section apply to the ATR_READY_F Sub-state. In this state, the NFC 
Forum Device expects a PSL_REQ or a DEP_REQ Command. 


Requirements 17: Listen Mode - ATR READY F Sub-state 
Listen Mode 


5.16.1.1 Upon receipt of a Valid DEP. REQ Command, the NFC Forum Device MUST send 
its DEP. RES Response and it MUST enter the TARGET. F Sub-state. 


5.16.1.2 Upon receipt of a Valid PSL. REQ Command with DSI set to 001b or 010b, the 
NFC Forum Device MUST send its PSL. RES Response and it MUST enter the 
TARGET F Sub-state. 


Refer to [DIGITAL] for details regarding DSI coding. 


5.16.1.3 Upon receipt of a Valid PSL. REQ Command with DSI set to 000b, the NFC Forum 
Device MUST send its PSL. RES Response and it MUST enter the TARGET A Sub- 
state. 


Refer to [DIGITAL ] for details regarding DSI coding. 


5.16.1.4 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send 
its RLS. RES Response and it MUST enter the IDLE Sub-state. 


5.16.1.5 Upon receipt of a Valid DSL. REQ Command, the NFC Forum Device MUST send 
its DSL. RES Response and it MUST enter the SLEEP AF Sub-state. 


5.16.1.6 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the ATR READY F Sub-state. 


5.17 TARGET F Sub-state 


The requirements in this section apply to the TARGET F Sub-state. In this state, the NFC Forum 
Device expects higher layer messages. 


Requirements 18: Listen Mode - TARGET F Sub-state 
Listen Mode 


5.17.1. | Upon receipt of a Valid DEP. REQ Command, the NFC Forum Device MUST send 
its DEP RES Response and it MUST stay the TARGET F Sub-state. 


5.17.1.2 Upon receipt of a Valid RLS_REQ Command, the NFC Forum Device MUST send 
its RLS. RES Response and it MUST enter the IDLE Sub-state. 


5.17.1.3 Upon receipt of a Valid DSL. REQ Command, the NFC Forum Device MUST send 
its DSL, RES Response and it MUST enter the SLEEP AF Sub-state. 


5.17.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the TARGET F Sub-state. 
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5.18 CARD EMULATOR 3 Sub-state 


The requirements in this section apply to the CARD EMULATOR 3 Sub-state. In this state, the NFC 


Forum Device expects Valid Commands according to the Type 3 Tag Platform as defined in 
[DIGITAL ]. 


Requirements 19: Listen Mode - CARD EMULATOR 3 Sub-state 
Listen Mode 


5.18.1.1 — Upon receipt of a Valid Command in compliance with the Type 3 Tag Platform as 
specified in [DIGITAL], the NFC Forum Device MUST send its Response and it 
MUST stay in the CARD EMULATOR 3 Sub-state. 


Upon receipt of a Proprietary Command, the NFC Forum Device MAY send its Response and 
stay in the CARD EMULATOR 3 Sub-state 


5.18.1.2 If OTHER, except for Proprietary Commands, the NFC Forum Device MUST NOT 
send a Response and it MUST stay in the CARD EMULATOR 3 Sub-state. 
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5.19 SLEEP AF Sub-state 


The requirements in this section apply to the SLEEP_AF Sub-state. In this state, the device has 
been deselected by means of a NFC-DEP DSL_REQ Command. The NFC Forum Device expects 
an ALL_REQ, a SENSF_REQ, or a CUP Command. 


Requirements 20: Listen Mode — SLEEP_AF Sub-state 
Listen Mode 


5.19.1.1 If CON_LISTEN_DEP_A=1 or CON_LISTEN_T4ATP=1, and upon receipt of a 
Valid ALL_REQ Command, the NFC Forum Device MUST send its SENS RES 
and it MUST enter the READY_A* Sub-state. 


5.19.1.2 If CON LISTEN DEP F-1 or CON LISTEN T3TP =1, upon receipt of a Valid 
SENSF REQ Command, the NFC Forum Device MUST compare the value of SC 
in the SENSF_REQ sequentially with the system code values contained in 
CON SYS CODE. If the values correspond according to the conditions defined 
below, the NFC Forum Device in Listen Mode MUST stop the comparison, it must 
send its Response, and it MUST enter the READY F Sub-state. 


An SC value in SENSF_REQ corresponds to the value contained in 
CON SYS CODE at index X: 


e If the value of SC in the SENSF REQ Command is equal to FFFFh, or 


e If the value of SC in the SENSF REQ is equal to the value of 
CON SYS CODEIX], or 


e Ifthe first byte of SC in the SENSF REQ Command has a value of FFh and the 
value of the second byte equals the value of the second byte of 
CON SYS CODELI[X], or 


e If the second byte of SC in the SENSF REQ Command has a value of FFh and 
the value of the first byte equals the value of the first byte of the 
CON SYS CODEIX] 


If the NFC Forum Device intends to include the RD bytes in the SENSF RES 
according to the requirements given in [DIGITAL], the value of the RD bytes must 
be equal to the matching CON SYS CODE value. 


5.19.1.3 If CON LISTEN T3TP -1 and the NFC Forum Device in Listen Mode has 
received a Valid CHECK or UPDATE Command as referenced in [DIGITAL] and 
defined in [T3TOP], the NFC Forum Device MUST send its Response and it MUST 
enter the CARD EMULATOR 3 Sub-state. 

If CON LISTEN T3TP =1, the NFC Forum Device in Listen Mode MAY enter the 

CARD EMULATOR 53 Sub-state after it has received a Proprietary Command for the Type 3 

Tag Platform. 


5.19.1.4 If OTHER, the NFC Forum Device MUST NOT send a Response and it MUST stay 
in the SLEEP AF Sub-state. 
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6 Poll Mode — Generic Requirements 


This section contains generic requirements that must be observed, independent of whether the 
NFC Forum Device chooses to implement the Activities described in this document or not. 


Requirements 21 contains the list of generic requirements. 
Requirements 21: Generic 


6.1.1.1 When the NFC Forum Device in Poll Mode sets the Operating Field to the 
Operating Field Off state (carrier off, as defined in [ANALOG]) other than for 
NFC-A modulation purposes, then the Operating Field MUST be set to Operating 
Field Off state for a time of at least tejenp_oFF. 


Refer to Appendix B for the value of trig p orr. 


6.1.1.2 When the NFC Forum Device in Poll Mode generates a Poll Command initially 
after setting the Operating Field to Operating Field On state or when generating 
subsequent Poll Command of different technology, these MUST be preceded by a 
period during which the NFC Forum Devices sends Unmodulated Carrier (as 
defined in [ANALOG]). The duration of this period is referred to as Guard Time 
and the NFC Forum Device MUST comply with the following Guard Times: 


e GT, for NFC-A 
e GTg for NFC-B 
e GT; for NFC-F 


If polling for NFC-F is preceded by polling for NFC-B, then GT; is equal to GTgr. 
Otherwise, GT; is equal to GTęp. 


For a more detailed definition of the Guard Times for each technology, see 
[DIGITAL]. 
Refer to Appendix B for the values of GTa, GT, GTpr and GTre. 


This does not apply to consecutive Poll Commands as well as a Poll Command following a 
Sleep Command. 


6.1.1.3 For the NFC Forum Device in Poll Mode, if the PSL_REQ Command is used, it 
MUST be sent as the first Command of the NFC-DEP Protocol Data Exchange, i.e., 
before the first DEP. REQ Command. 


e The PSL_REQ (A) as used in the state machine is a PSL_REQ with DSI set to 
000b. 


e The PSL_REQ (F) as used in the state machine is a PSL_REQ with DSI set to 
001b or 010b. 


Refer to [DIGITAL] for the coding of the PSL_REQ Command. 


6.1.1.4 An NFC Forum Device MUST perform RF Collision Avoidance (see Section 7) 
before generating an Operating Field. 


6.1.1.5 When the NFC Forum Device in Poll Mode includes Poll Commands for one or 
more Proprietary Technologies, then the Proprietary Technologies MUST be polled 
after the NFC Technology(ies). 
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6.1.1.6 For introducing Proprietary Technologies, the NFC Forum Device MUST wait with 
Unmodulated Carrier for a period after a Poll Command. The duration of this period 
is the sum of FDT/FWT for the Poll Command and the Proprietary Technology 
Guard Time. 


The resulting timings are: 


e If polling for Proprietary Technology is preceded immediately by polling for 
NFC-A, then the time PTGTA T FDTĄ LiSTEN,MAX MUST be applied. 


e If polling for Proprietary Technology is preceded immediately by polling for 
NFC-B, then the time PTGTg + FWTsensp MUST be applied. 


e If polling for Proprietary Technology is preceded immediately by polling for 
NFC-F, then the time PTGTr + FDTr,isrEN,sENsF REQ MUST be applied. 


Refer to [DIGITAL] for details regarding FDTa Lisren,max, FWTsensB, and 
FDTFLISTEN,SENSF REQ- 


Refer to Appendix B for the values of PTGT,, PTGTsg, and PTGTr. 
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7 Poll Mode — RF Collision Avoidance 


Figure 2 shows the flow chart for RF Collision Avoidance that shall be applied by the NFC 
Forum Device before generating an Operating Field. 


+ NU 


sense field 


put field on 


— + 


Figure 2: RF Collision Avoidance — Flow Chart 


Requirements 22 contains the list of RF Collision Avoidance requirements. Symbols in this 
section refer to corresponding symbols in Figure 2. 
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Requirements 22: RF Collision Avoidance 
Poll Mode 


7.1.1.1 Symbol 1: 


The NFC Forum Device MUST check during a time Tp + n X Trew No Remote Field 
Sensed. 


e Ti MUST be greater than 4096/fc. 
e = =Trew MUST be equal to 512/fc. 
e The integer value of 0 < n < 3 MUST be randomly generated. 


7.1.1.2 Symbol 2: 


If No Remote Field Sensed, after having listened according to Symbol 1, the NFC 
Forum Device MUST proceed to Symbol 3. 


Otherwise, the NFC Forum Device MUST conclude RF Collision Avoidance. 
7.1.1.3 Symbol 3: 


The NFC Forum Device MUST turn the Operating Field to the Operating Field On 
state, as defined in [ANALOG] and it MUST conclude RF Collision Avoidance. 
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8 Poll Mode — Activity and Profile Model 


Activities combine elementary blocks of [DIGITAL] into functional blocks. Each functional 
block has a dedicated purpose, with well defined pre-conditions and post-conditions. It provides a 
level of detail on the Initiator/Reader functionality that is not already specified within 
[DIGITAL]. 


The Activity manages the dialogue with another device, using the Commands and Responses 
specified in [DIGITAL]. To perform its task, it has a well-defined set of algorithms, with one 
algorithm per Technology if necessary. 


= 
2 
je 
po) 
D 
T 
O 
O 
Greedy 
Input Activity «—— Collection 


Output 


Figure 3: Activity 


An Activity may have any of the following interfaces as shown in Figure 3: 
e Configuration Parameters 

e Input Parameters 

e Output Parameters 

e Greedy Collection 


Configuration Parameters and Input Parameters provide the necessary flexibility on how to use 
the algorithm. As part of its processing, the Activity collects information on the other device. 
While this information may not be directly relevant for this Activity, it is stored in the Greedy 
Collection, so that it can be used by other Activities or the Resolution Process. Output Parameters 
provide the results of the Activity into the Resolution Process. 


Activities are managed by the Resolution Process, which is a decision process controlled by the 
adjacent upper layer. The scope of the Resolution Process is limited to the identification of and 
the Input Parameter setting for the next Activity. The other responsibilities of the adjacent upper 
layer, beyond the Resolution Process (such as controlling the display, collecting user input, 
performing exception handling, etc.) are outside the scope of this specification. 
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The following rules for the framework around Activities apply: 


During normal processing, Activities are not interrupted by the adjacent upper layer. If the 
adjacent upper interrupts an Activity, this is an exception. 


If an error occurs within an action block, then an error-handling task may interrupt the 
Activity processing. The error-handling task may choose to proceed inside the current 
Activity or to abort it. Error handling has to conform with [DIGITAL]. Care has to be taken 
with the integrity of the Greedy Collection. 


The Resolution Process can start an Activity only if the pre-conditions of the Activity are 
fulfilled. 


The installation of the Resolution Process and the initialization of the needed Configuration 
Parameters have to be done before any Activity is started. 


The Resolution Process and the Configuration Parameters remain valid as long as a Profile 
remains active (i.e., until the control is handed back to the adjacent upper layer). 


A Profile is comprised of an initialization, a Resolution Process, Activities, the Greedy 
Collection, and a Clean-up, as shown in Figure 4: 


— Initialization 
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< > 
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R —> 
Resolution s 
——— Activity |— 
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d y 
Clean-up 
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Figure 4: Profile 
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The Profile is defined by: 
e The Resolution Process 
e The values chosen for the Configuration Parameters 


During the Initialization of a Profile, the Configuration Parameters as needed by the included 
Activities are set. In the case of a Poll Mode Profile, RF Collision Avoidance takes place (see 
Section 7). 


The Clean-up of a Profile erases the Greedy Collection and, if a Poll Mode Profile, the Operating 
Field is turned to the Operating Field Off state, in accordance with Requirement 6.1.1.1. 


In the absence of user intervention and errors, a Profile describes the deterministic behavior of the 
included Activities. 


The way a Profile unfolds and therefore the order of the Activities that are called depend on the 
other device(s) encountered. 


The Activities defined in this document are contained in Section 9. Building on those Activities, 
Section 10 defines a set of Profiles covering the NFC Forum communication use cases. 
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An Activity uses: 
e Technology-independent pre-conditions and post-conditions 


e Technology-independent Configuration Parameters, except for the Technology Detection 
Activity and the Device Activation Activity 


e Technology-dependent Algorithms, using the Configuration Parameters in a technology- 
specific manner 


Configuration Parameters are independent from the other device and typically survive multiple 
transactions. This distinguishes them from the Greedy Collection,which stores information 
learned from the other device and therefore varies with each transaction. 


The description of each Activity is structured as follows: 
e The pre-conditions are described by: 

e The input from the Resolution Process 

e The Configuration Parameters 

e The information collected previously in the Greedy Collection 
e The post-conditions are described by: 

e The information that can be used by the Resolution Process 

e The information currently in the Greedy Collection 
e The algorithm is described through: 

e The flow chart 

e The requirements 
The defined Activities can be combined in Profiles (see Section 10). 
The remainder of this section lists requirements and contains a detailed definition of each 
Activity. 
9.1 Activities - Requirements 


This section contains requirements that must be observed when implementing the Activities 
described in this document. 


Requirements 23: Activities - General 


9.1.1.1 For each combination of Activities in Poll Mode, the Operating Field MUST be in 
the Operating Field On state (see Section 7). 


9.1.1.2 For each combination of Activities in Poll Mode, the first Activity MUST be the 
Technology Detection Activity. 
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9.2 Technology Detection Activity 


This section describes the Technology Detection Activity. The purpose of the Technology 
Detection Activity is to scan for devices of certain technologies that are within range. 


9.2.1 Pre-conditions 


The Configuration Parameters for the Technology Detection Activity are listed in Table 8: 


Table 8: Technology Detection Activity — Configuration Parameters 


Name Format Size Description 


CON_POLL_A binary 1 bit 1b: Poll for NFC-A Technology 
Ob: Do not poll for NFC-A Technology 


CON_POLL_B binary 1 bit 1b: Poll for NFC-B Technology 
Ob: Do not poll for NFC-B Technology 


CON_POLL_F binary 1 bit 1b: Poll for NFC-F Technology 
Ob: Do not poll for NFC-F Technology 


CON_POLL_P binary 1 bit 1b: Poll for Proprietary Technology 
Ob: Do not poll for Proprietary Technology 


CON_BAIL_OUT_A | binary 1 bit 1b: Bail-out after NFC-A 
Ob: No bail-out after NFC-A 


CON_BAIL_OUT_B | binary 1 bit 1b: Bail-out after NFC-B 
Ob: No bail-out after NFC-B 


CON_BITR Integer 1 Byte Bit rate for NFC-F 
2: 212 kbps 
3: 424 kbps 
NOTE There is no bail-out option for NFC-F as bail-out is mandatory before polling for a 


Proprietary Technology and the NFC Forum Device always checks whether an NFC 
Technology has been detected. The bail-out options for NFC-A and NFC-B are 
introduced to allow optimization. 


There are no Input Parameters requested from the Resolution Process for this Activity. 


There is no data needed from the Greedy Collection for this Activity. 
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The output of the Technology Detection Activity is listed in Table 9: 


Table 9: Technology Detection Activity - Output Parameters 


Name Format Size Description 
FOUND_A binary 1 bit 1b: NFC-A Technology found 
Ob: NFC-A Technology not found 
FOUND_B binary 1 bit 1b: NFC-B Technology found 
Ob: NFC-B Technology not found 
FOUND_F binary 1 bit 1b: NFC-F Technology found 
Ob: NFC-F Technology not found 
NOTE The outcome of polling for proprietary technology is outside of the scope of this 


specification and therefore such result does not appear as an Output Parameter. 


The data returned to the Greedy Collection is listed in Table 10: 


Table 10: Technology Detection Activity — Output into Greedy Collection 


Name Format 


GRE_POLL_A[] | array of 
Byte 
Sequences 


GRE_POLL_B[] | array of 
Byte 


Sequences 


GRE_POLL_F[] | array of 
Byte 


Sequences 


Size 


variable 


variable 


variable 


Description 


Each element contains a Response to an 
ALL_REQ or SENS_REQ Command. For NFC- 
A, the array is limited to one element. 


Each element contains a Response to an 
ALLB_REQ or SENSB_REQ Command. For 
NFC-B, the array is limited to one element. 


Each element contains a Response to an 
SENSF_REQ Command. For NFC-F, the array 
is limited to four elements. 


9.2.3 Flow Chart and Requirements 
The NFC Forum Device uses a fixed polling order: NFC-A, NFC-B, NFC-F. 


If bail-out is set for a particular Technology, the NFC Forum Device in Poll Mode checks 
whether this Technology or a Technology polled for earlier has been detected. If so, the NFC 
Forum Device stops further polling; if not, the NFC Forum Device continues polling for the 


remaining technologies. 


After polling for NFC-F, and therefore, before polling for a Proprietary Technology, the NFC 
Forum Device always checks whether a Technology has been detected. 
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Figure 5 shows the processing flow for the NFC Forum Device during the Technology Detection 


Activity. 
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Figure 5: Technology Detection Activity — Flow Chart 


Symbols in this section refer to corresponding symbols in Figure 5. 
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Requirements 24: Technology Detection Activity 


Symbol 1: 

The NFC Forum Device MUST initialize the following flags to zero: 
e FOUND A:-0 

e FOUND B:-0 

e FOUND F:-0 

Symbol 2: 


If the NFC Forum Device is configured to poll for NFC-A Technology (i.e., 
CON POLL A - 1), then the NFC Forum Device MUST proceed to Symbol 3. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 8. 
Symbol 3: 


Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier 
for at least GTą. 


Refer to [DIGITAL] for the value of GTą. 
Symbol 4: 


The NFC Forum Device MUST send an ALL. REQ or SENS REQ Command and it 
MUST wait for a Response afterward as defined in [DIGITAL ]. 


Symbol 5: 


If the NFC Forum Device does not receive a Response to the ALL REQ or 
SENS REQ Commands, then NFC Forum Device MUST proceed to Symbol 8. 


Otherwise, the NFC Forum Device MUST store the Response in GRE POLL. A[] 
and it MUST proceed to Symbol 6. 


Symbol 6: 
The NFC Forum Device MUST set FOUND A to 1. 
Symbol 7: 


If the NFC Forum Device is configured for bail-out upon detection of NFC-A 
Technology (i.e., CON. BAIL OUT A = 1), then the NFC Forum Device MUST 
conclude the Technology Detection Activity. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 8. 
Symbol 8: 


If the NFC Forum Device is configured to poll for NFC-B Technology (i.e., 
CON POLL B 1), then the NFC Forum Device MUST proceed to Symbol 9. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 15. 
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9.2.3.10 


9.2.3.11 


9.2.3.12 


9.2.3.13 


9.2.3.14 


9.2.3.15 
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9.2.3.17 
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Symbol 9: 


Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier 
for at least GTg. 


Refer to [DIGITAL] for the value of GT. 
Symbol 10: 


The NFC Forum Device MUST send an ALLB REQ or a SENSB REQ Command 
with number of slots set equal to 1 (N=1) and it MUST wait for a Response afterward 
as defined in [DIGITAL]. 


Symbol 11: 


If the NFC Forum Device does not receive a Response to the ALLB_REQ or 
SENSB_REQ Commands, then the NFC Forum Device MUST proceed to 
Symbol 13. 


Otherwise, the NFC Forum Device MUST store the Response in GRE_POLL_B[] 
and it MUST proceed to Symbol 12. 


Symbol 12: 
The NFC Forum Device MUST set FOUND B to 1. 
Symbol 13: 


If the NFC Forum Device is configured for bail-out upon detection of NFC-B 
Technology (i.e., CON_BAIL_OUT_B = 1), then the NFC Forum Device MUST 
proceed to Symbol 14. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 15. 
Symbol 14: 


If FOUND_A or FOUND_B has a value equal to 1, the NFC Forum Device MUST 
conclude the Technology Detection Activity. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 15. 
Symbol 15: 


If the NFC Forum Device is configured to poll for NFC-F Technology (i.e., 
CON_POLL_F = 1), then the NFC Forum Device MUST proceed to Symbol 16. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 20. 
Symbol 16: 


Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier 
for at least GT. 


For more details on GTp, see requirement 6.1.1.3. 
Symbol 17: 


The NFC Forum Device MUST send a SENSF_REQ Command with number of slots 
equal to 4 (TSN = 03h), SC = FFFFh, RC = 00h at the bit rate configured by the 
CON_BITR and it MUST wait for a Response afterward as defined in [DIGITAL]. 
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Symbol 18: 


If the NFC Forum Device does not receive a Response to the SENSF_REQ 
Command, then the NFC Forum Device MUST proceed to Symbol 20. 


Otherwise, the NFC Forum Device MUST store the Response(s) in GRE POLL FT] 
and it MUST proceed to Symbol 19. 


Symbol 19: 
The NFC Forum Device MUST set FOUND F to 1. 
Symbol 20: 


If FOUND A or FOUND B or FOUND F has a value equal to 1, the NFC Forum 
Device MUST conclude the Technology Detection Activity. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 21. 
Symbol 21: 


If the NFC Forum Device is configured to poll for a Proprietary Technology (i.e., 
CON_POLL_P = 1), then the NFC Forum Device MUST proceed to Symbol 22. 


Otherwise, the NFC Forum Device MUST conclude the Technology Detection 
Activity. 


Symbol 22: 


Before proceeding, the NFC Forum Device MUST maintain an Unmodulated Carrier 
for a guard time as specified in 6.1.1.2. 


Symbol 23: 


Further processing and output Parameters of proprietary technology is out of scope of this 
specification. 
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9.3 Collision Resolution Activity 


This section describes the Collision Resolution Activity. 


9.3.1  Pre-conditions 


The Configuration Parameters for the Collision Resolution Activity are listed in Table 11: 


Table 11: Collision Resolution Activity — Configuration Parameters 


Name Format Size Description 
CON DEVICES LIMIT Hexadecimal | 1 Byte CON DEVICES LIMIT = 00h: 


No identifier has to be resolved 
when a collision is detected. 


CON DEVICES LIMIT > 00h: 
Number of resolved NFCIDx 
device identifiers beyond which 
the collision resolution process 
can stop resolving when collisions 
are still pending. 


CON ADV FEAT Binary 1 bit Ob: Advanced protocol features 
not activated 


1b: Advanced protocol features 
activated 


CON ANTICOLL Binary 1 bit Ob: Do not use anti-collision 
1b: Use anti-collision 


The Input Parameters for the Collision Resolution Activity are listed in Table 12: 
Table 12: Collision Resolution Activity — Input Parameters 


Name Format Size Description 


INT TECH SEL binary 2 bit 00b: Resolve NFC-A Technology 
01b: Resolve NFC-B Technology 
10b: Resolve NFC-F Technology 
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The data requested from the Greedy Collection is listed in Table 13: 


Table 13: Collision Resolution Activity — Input from Greedy Collection 


Name Format Size Description 

GRE POLL A[] array of variable Each element contains a Response 
Byte to an ALL. REQ or SENS REQ 
Sequences Command. 


For NFC-A, the array is limited to 
one element. 


GRE POLL B[] array of variable Each element contains a Response 
Byte to an ALLB_REQ or 
Sequences SENSB REQ Command. For 
NFC-B, the array is limited to one 
element. 
GRE POLL F[] array of variable Each element contains a Response 
Byte to an SENSF REQ Command. 
Sequences For NFC-F, the array is limited to 


four elements. 


9.3.2  Post-conditions 


The Output Parameters returned to the Resolution Process are listed in Table 14: 


Table 14: Collision Resolution Activity - Output Parameters 


Name Format Size Description 
INT NFCIDX[n], array of variable | Contains identifiers of the devices 
n=ltoN identifiers resolved. N denotes the number of 


devices resolved. The size of each 
identifier is technology dependent. 


INT_NFCIDX_SLEEP[n], | Binary 1 bit Ob: Device not in sleep state 
n=ltoN 1b: Device in sleep state 
INT_COLL_PEND Binary 1 bit Ob: No collision pending 


1b: Collisions pending 
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The data returned to the Greedy Collection is listed in Table 15: 


Table 15: Collision Resolution Activity — Output into Greedy Collection 


Name Format Size 


GRE SEL RES[] array of variable 
Byte 


Sequences 


GRE, SENSB RES[] | array of variable 
Byte 


Sequences 


GRE, SENSF RES[] | array of variable 
Byte 


Sequences 


Description 


Response of each identified device. 


Each element contains a SEL. RES Response 
from an NFC-A device. 


Response of each identified device. 


Each element contains a Response to an 
ALLB REQ or SENSB REQ Command from 
an NFC-B device. 


Response of each identified device. 


Each element contains a Response to an 
SENSF REQ Command from an NFC-F device. 


9.3.3 Flow Chart (Normative) 


The Collision Resolution Activity to be performed depends on the value of the INT TECH, SEL 
parameter and is defined in the normative Figure 6. 


C 


Figure 6: Collision Resolution Activity (Sheet 1, Entry) - Normative Flow Chart 
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9.3.4 Flow Chart and Requirements for NFC-A 


The purpose of the NFC-A-related part of the Collision Resolution Activity is to identify an NFC 
Forum Device within range that has activated support for NFC-A Technology (subset). The 
algorithm works as follows: 


The algorithm selects one device after the other. Every time a collision is detected, the 
algorithm continues with the valid bits of the NFCID1 CLn followed by a 1b. This way, 
multiple devices can be identified by selecting all cascade levels of one device before 
restarting the algorithm to select the next device. Before restarting the algorithm, the device 
identified is sent to SLEEP_A Sub-state to exclude it from the remaining collision resolution 
process. 


The NFC Forum Device can be configured to shorten the process by using the 
CON_DEVICES_LIMIT Configuration Parameters. The CON_DEVICES_LIMIT is used to 
conclude the NFC-A Collision Resolution Activity after identification of a set number of devices, 
even if collisions are still pending. 


If the CON_DEVICES_LIMIT is set to zero, then collision detection only is performed. That is, 
if a collision is detected, the NFC Forum Device concludes the NFC-A Collision Resolution 
Activity indicating a collision without identifying any device. 


Figure 7 describes the NFC-A-related part of the Collision Resolution Activity. 
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Figure 7: Collision Resolution Activity (Sheet 2, connector A, NFC-A) — Flow Chart 
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Symbols in this section refer to corresponding symbols in Figure 7. 
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Requirements 25: Collision Resolution Activity - NFC-A 


Symbol 0: 


If the SENS RES is a Valid Response and indicates the bit frame SDD support, the 
NFC Forum Device MUST proceed to Symbol 1. 


Otherwise, the NFC Forum Device proceeds with Symbol 22. 
Symbol 1: 


If CON. ANTICOLL has a value of 1, the NFC Forum Device MUST proceed to 
Symbol 2. 


Otherwise, the NFC Forum Device proceeds with Symbol 22. 
Symbol 2: 


The NFC Forum Device MUST initialize the device counter with a value of 0 and 
INT COLL PEND with a value of 0. The NFC Forum Device MUST initialize 
INT NFCIDX SLEEP[] with 0. 


Symbol 3: 
The NFC Forum Device MUST select SDD cascade level 1. 
Symbol 4: 


The NFC Forum Device MUST assign SEL. CMD with the code for the selected 
SDD cascade level. 


Symbol 5: 


The NFC Forum Device MUST set SEL PAR to the value of 20h, indicating that no 
data bits are following. 


Symbol 6: 


The NFC Forum Device MUST send the SDD REQ Command. Refer to [DIGITAL] 
for the coding of the SDD REQ Command. 


Symbol 7: 


If the NFC Forum Device detects a Collision in the Response to the SDD REQ 
Command, the NFC Forum Device MUST proceed to Symbol 8. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 13. 
Symbol 8: 


The NFC Forum Device MUST set INT COLL. PEND to a value of 1 to indicate a 
pending collision. 
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Symbol 9: 


If the CON_DEVICES_LIMIT has a value of 0, then the NFC Forum Device MUST 
conclude the NFC-A Collision Resolution Activity (i.e., the NFC Forum Device is 
configured to perform collision detection only). 


Otherwise, the NFC Forum Device MUST proceed to Symbol 10. 
Symbol 10: 


The NFC Forum Device MUST set SEL_PAR to a value that specifies the number of 
valid bits of NFCID1 CLn. The valid bits are part of the NFCID1 CLn that was 
received before a collision occurred, followed by 1b (i.e., the position of the first 
collision in the Response to the previous SDD_REQ Command is set to 1b). 


Symbol 11: 


The NFC Forum Device MUST send the SDD_REQ Command including the data 
bits as indicated by SEL_PAR. 


Symbol 12: 


If the NFC Forum Device detects a Collision in the Response to the SDD_REQ 
Command, the NFC Forum Device MUST proceed to Symbol 10. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 14. 
Symbol 13: 


The NFC Forum Device MUST reset INT_COLL_PEND to a value of 0 and proceed 
to Symbol 14. 


Symbol 14: 


The NFC Forum Device MUST send the SEL_REQ Command. Refer to [DIGITAL] 
for the coding of the SEL_REQ Command. 


Symbol 15: 
The NFC Forum Device MUST check the cascade tag of the SEL_RES Response. 


If the cascade tag indicates that NFCID1 is complete, then the NFC Forum Device 
MUST proceed to Symbol 17. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 16. 
Symbol 16: 

The NFC Forum Device MUST increase the cascade level. 

The NFC Forum Device MUST proceed to Symbol 4. 

Symbol 17: 
The NFC Forum Device MUST increment the device counter by 1. 
Symbol 18: 


The NFC Forum Device MUST store the SEL_RES Response in GRE_SEL_RES[] 
and it MUST store the NFCID1 identifier in INT NFCIDX[device counter-1]. 
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9.3.4.22 


9.3.4.23 


9.3.4.24 


9.3.4.25 


9.3.4.26 


9.3.4.27 
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Symbol 19: 


If INT COLL PEND has a value of 1 and the device counter is lower than the 
CON_DEVICES_LIMIT, then the NFC Forum Device MUST proceed to Symbol 20. 


Otherwise, the NFC Forum Device MUST conclude the NFC-A Collision Resolution 
Activity. 


Symbol 20: 


The NFC Forum Device MUST send a SLP_REQ Command to put the device with 
identifier INT NFCIDX[device counter - 1] in the SLEEP. A Sub-state and it MUST 
memorize the information that a SLP. REQ Command has been sent to the device by 
setting INT NFCIDX . SLEEP[device counter - 1] equal to 1. 


Symbol 21: 


The NFC Forum Device MUST send the SENS REQ Command and it MUST wait 
for the SENS. RES Response afterward, as specified in [DIGITAL]. 


The NFC Forum Device MUST proceed to Symbol 3. 

Symbol 22: 

The NFC Forum Device sends the RID Command as indicated in [DIGITAL]. 
Symbol 23: 


If the NFC Forum Device detects a Collision in the Response to the RID, the NFC 
Forum Device MUST proceed to Symbol 24. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 25. 
Symbol 24: 


The NFC Forum Device MUST set INT COLL. PEND to 1b and conclude the NFC- 
A Collision Resolution Activity. 


Symbol 25: 
The NFC Forum Device MUST set INT COLL. PEND to Ob. 
Symbol 26: 


The NFC Forum Device MUST increment the device counter by 1 and store the RID 
Response, including identifier UIDO...UID3 in INT NFCIDX[device counter-1], and 
conclude the NFC-A Collision Resolution Activity. 


NFC Activity Specification Page 66 


Poll Mode — Activities 


9.3.5 Flow Chart and Requirements for NFC-B 


The purpose of the NFC-B-related part of the Collision Resolution Activity is to identify an NFC 
Forum Device within range that has activated support for NFC-B Technology. The algorithm 
works as follows: 


If the Technology Detection resulted in a Valid SENSB_RES Response (i.e., no collisions), 
then the NFC Forum Device extracts the identifier and stores it in INT NFCIDXT[].If there is 
just one device detected or just one device is resolved, than the device is left in the 
READY_B_DECL Sub-state. 


If the Technology Detection resulted in an invalid SENSB_RES Response (i.e., collisions), then 
the NFC Forum Device polls with the number of timeslots set to 1. The NFC Forum Device saves 
each Valid Response to a SENSB_REQ or SLOT MARKER in GRE_SENSB_RES[]. Each 
Valid Response results in an identifier that is stored in INT_NFCIDX[] and each device identified 
is subsequently put in the SLEEP_B Sub-state, except the last resolved device (it stays in the 
READY_B_DECL Sub-state). 


As long as collisions occur and no device has been identified yet, the NFC Forum Device 
increments the number of time slots and sends new SENSB_REQ Commands. If there are still 
collisions after having completed the collision resolution with the maximum number of time slots, 
no further attempt is made to isolate the identifiers. 


When at least one device has already been identified, the number of slots is not further 
incremented. 


The NFC Forum Device can be configured to shorten the process by using the 
CON_DEVICES_LIMIT parameter. The parameter is used to conclude the NFC-B Collision 
Resolution Activity after identification of a set number of devices, even if collisions are still 
pending. 

If this parameter is set to zero, then collision detection only is performed. That is, if a collision is 
detected, the NFC Forum Device concludes the NFC-B Collision Resolution Activity. 


NOTE In this version of the document, NFC Forum advanced protocol features are not 
supported, and therefore, the NFC Forum Device only polls for devices not 
supporting NFC Forum advanced protocol features. 


Figure 8 describes the NFC-B-related part of the Collision Resolution Activity. 
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Figure 8: Collision Resolution Activity (Sheet 3, connector B, NFC-B) — Flow Chart 


Symbols in this section refer to corresponding symbols in Figure 8. 
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Requirements 26: Collision Resolution Activity - NFC-B 


Poll Mode 


9.3.5.1 Symbol 0: 


The NFC Forum Device MUST assign a parameter containing the device counter and 
it MUST initialize this parameter with 0. 


The NFC Forum Device MUST assign a parameter containing the number of slots 
and it MUST initialize this parameter with 1. 


The NFC Forum Device MUST initialize INT NFCIDX SLEEPT[] with 0. 
9.3.5.2 Symbol 1: 


The NFC Forum Device MUST read GRE_POLL_B[1], containing the most recent 
SENSB_RES Response. 


If the SENSB_RES Response is Valid, then the NFC Forum Device MUST proceed 
to Symbol 3. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 2. 
9.3.5.3 Symbol 2: 


If the CON_DEVICES_LIMIT has a value of 0 (i.e., the NFC Forum Device is 
configured to perform collision detection only), then the NFC Forum Device MUST 
proceed to Symbol 19. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 3. 
9.3.5.4 Symbol 3: 


The NFC Forum Device MUST assign a parameter containing the current slot 
number and it MUST initialize this parameter with 0. 


The NFC Forum Device MUST initialize INT_COLL_PEND with 0. 
9.3.5.5 Symbol 4: 


If the NFC Forum Device did not receive a Response in the slot corresponding to the 
current slot number, then the NFC Forum Device MUST proceed to Symbol 11. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 5. 
9.3.5.6 Symbol 5: 


If the last SENSB_RES Response that the NFC Forum Device has memorized is 
Valid, then the NFC Forum Device MUST proceed to Symbol 7. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 6. 
9.3.5.7 Symbol 6: 
The NFC Forum Device MUST set INT_COLL_PEND to 1. 
The NFC Forum Device MUST proceed to Symbol 11. 
9.3.5.8 Symbol 7: 


The NFC Forum Device MUST increment the device counter. 
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9.3.5.9 


9.3.5.10 


9.3.5.11 


9.3.5.12 


9.3.5.13 


9.3.5.14 


9.3.5.15 


9.3.5.16 


Poll Mode — Activities 


Symbol 8: 


The NFC Forum Device MUST store the NFCIDO identifier to 
INT_NFCIDX[device counter-1]. 


Symbol 9: 


If the device counter is lower than the CON_DEVICES_LIMIT, then the NFC Forum 
Device MUST proceed to Symbol 10. 


Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution 
Activity. 


Symbol 10: 


The NFC Forum Device MUST send a SLPB_REQ Command to put the device 
resolved in the SLEEP_B Sub-state and it MUST set 
INT_NFCIDX_SLEEP[device counter-1] equal to 1. 


Symbol 11: 


The NFC Forum Device MUST increment the current slot number, indicating the 
current slot in which to receive SENSB_RES Responses. 


Symbol 12: 


If the current slot number is equal to the last slot, then the NFC Forum Device MUST 
proceed to Symbol 13. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 20. 
Symbol 13: 


If INT_COLL_PEND has a value of 1, then the NFC Forum Device MUST proceed 
to Symbol 14. 


Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution 
Activity. 


Symbol 14: 


If subsequent to the last SENSB_REQ Command, the NFC Forum Device resolved 
an identifier of a responding device (i.e., the identifier of the responding device has 
been memorized), then the NFC Forum Device MUST proceed to Symbol 17. 


Otherwise (i.e., no identifier was resolved), the NFC Forum Device MUST proceed 
to Symbol 15. 


Symbol 15: 


If the number of slots is equal to the maximum value allowed, then the NFC Forum 
Device MUST conclude the NFC-B Collision Resolution Activity. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 16. 


The maximum value allowed for the number of slots is specified in [DIGITAL] 
within the SENSB REQ Command. 
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9.3.5.21 
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Symbol 16: 


The NFC Forum Device MUST increase the number of slots to the next value 
allowed. The values allowed for the number of slots are specified in [DIGITAL |], 
within the SENSB REQ Command. 


The NFC Forum Device MUST proceed to Symbol 18. 
Symbol 17: 


If the device counter is lower than the CON DEVICES LIMIT, then the NFC Forum 
Device MUST proceed to Symbol 18. 


Otherwise, the NFC Forum Device MUST conclude the NFC-B Collision Resolution 
Activity. 


Symbol 18: 


The NFC Forum Device MUST send a SENSB. REQ Command, MUST wait for the 
SENSB RES Response afterward as specified in [DIGITAL], and it MUST proceed 
to Symbol 4. 


The NFC Forum Device MUST proceed to Symbol 3. 
Symbol 19: 


The NFC Forum Device MUST set INT COLL. PEND to 1 and it MUST conclude 
the NFC-B Collision Resolution Activity. 


Symbol 20: 


The NFC Forum Device MUST send a SLOT MARKER Command indicating the 
current slot. 


The NFC Forum Device MUST proceed to Symbol 4. 
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9.3.6 Flow Chart and Requirements for NFC-F 


The purpose of the NFC-F-related part of the Collision Resolution Activity is to identify an NFC 
Forum Device that has activated support for NFC-F Technology (subset). The algorithm works as 
follows: 
The NFC Forum Device retrieves the number of devices that already have been identified. If 
this number is lower than the value of CON DEVICES LIMIT, then the NFC Forum Device 
polls again by sending a SENSF_REQ Command with the maximum number of time slots 
set. 


Figure 9 describes the NFC-F related part of the Collision Resolution Activity. 
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Figure 9: Collision Resolution Activity (Sheet 4, connector F, NFC-F) — Flow Chart 


Symbols in this section refer to corresponding symbols in Figure 9. 
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Requirements 27: Collision Resolution Activity - NFC-F 


Symbol 0: 


The NFC Forum Device MUST set INT COLL. PEND to 0 and it MUST initialize 
INT NFCIDX SLEEP[] with 0. 


Symbol 1: 


The NFC Forum Device MUST assign a parameter device counter and it MUST 
initialize this parameter with 0. 


The NFC Forum Device MUST read GRE_POLL_F[], which contains the 
SENSF_RES Response(s) to the preceding SENSF_REQ Commands. For each Valid 
SENSF_RES Response, the NFC Forum Device MUST increment the device counter 
by 1, it MUST extract the NFCID2, and it MUST store it in INT_NFCIDX[device 
counter]. 


Symbol 2: 


The NFC Forum Device MUST copy each Valid SENSF_RES Response contained in 
GRE_POLL_F[] into GRE_SENSF_RESI|]. 


Symbol 3: 


If the value of device counter (the number of Valid SENSF_RES Responses retrieved 
from Greedy Collection) is lower than the value of the CON_DEVICES_LIMIT 
parameter, the NFC Forum Device MUST proceed to Symbol 4. Otherwise, the NFC 
Forum Device MUST conclude the NFC-F Collision Resolution Activity. 


Symbol 4: 


The NFC Forum Device MUST send a SENSF_REQ Command with TSN set to Ofh, 
RC set to 00h and SC set to FFFFh and it MUST wait for a Response afterward as 
defined in [DIGITAL]. 


Symbol 5: 


The NFC Forum Device MUST remove all entries from GRE. SENSF RES[] and 
then store any Valid SENSF. RES Response(s) received during processing of Symbol 
4in GRE SENSF RES[]. 


Symbol 6: 


The NFC Forum Device MUST remove all entries from INT NFCIDX[]. Then, the 
NFC Forum Device MUST extract the NFCID2 for each entry in 
GRE SENSF RES[]| and it MUST store NFCID2 in INT NFCIDXT[]. 


Afterward, the NFC Forum Device MUST conclude the NFC-F Collision Resolution 
Activity. 
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9.4 Device Activation Activity 


This section describes the Device Activation Activity. 


Poll Mode — Activities 


The Device Activation Activity activates one device out of the set of devices identified during 
Technology Detection Activity and Collision Resolution Activity. The resolution process decides 


which device to activate. 


9.4.1 Pre-conditions 


The Configuration Parameters for the Device Activation Activity are listed in Table 16: 


Table 16: Device Activation Activity — Configuration Parameters 


Name 


CON_ATR 


CON_GB 


CON_RATS 


NFC Activity Specification 


Format 


Hexadecimal 


Hexadecimal 


Hexadecimal 


Size 


3 Bytes 


n Bytes 


1 Byte 


Description 


ATR_REQ Command parameter 


- Refer to [DIGITAL] (Byte 13 
of ATR_REQ) for the coding 
of Byte 1. 


- Refer to [DIGITAL] (Byte 14 
of ATR_REQ) for the coding 
of Byte 2. 


- Refer to [DIGITAL] (Byte 15 
of ATR_REQ) for the coding 
of Byte 3. 


- Refer to [DIGITAL] (Byte 16 
of ATR_REQ) for the coding 
of Byte 4. 


General bytes of the ATR_REQ 
or Higher Layer INF of ATTRIB 


Refer to [DIGITAL] Byte 17+n of 
ATR_REQ and [DIGITAL] Byte 
10+n for ATTRIB. 

For the ATR_REQ, these bytes 
contain the General Bytes 
(G,0...G;n) as information for 
LLCP. 

For ATTRIB, these bytes contain 
High Layer INF. 


RATS Command Parameters 
Refer to [DIGITAL] (Byte 2 of 
RATS Command) for the coding 
of Byte 1. 
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Name Format Size 


CON_ATTRIB hexadecimal | 3 Bytes 


Poll Mode — Activities 


Description 


ATTRIB Command Parameters 

- Refer to [DIGITAL] (Byte 6 
of ATTRIB Command) for 
the coding of Byte 1. 

- Refer to [DIGITAL] (Byte 7 
of ATTRIB Command) for 
the coding of Byte 2. 

- Refer to [DIGITAL] (Byte 8 
of ATTRIB Command) for 
the coding of Byte 3. 

- Refer to [DIGITAL] (Byte 9 
of ATTRIB Command) for 
the coding of Byte 4. 


CON_BITR_NFC_DEP Integer 1 Byte 


Desired Bit rate 
- 0: maintain the bit rate 
- 1:106 kbps 
- 2: 212 kbps 
- 3: 424 kbps 


The Input Parameters for the Device Activation Activity are listed in Table 17: 


Table 17: Device Activation Activity — Input Parameters 


Name Format Size Description 


INT_TECH_SEL binary 2 bit Technology to activate 


00b: NFC-A Technology 
01b: NFC-B Technology 
10b: NFC-F Technology 


INT_INDEX Integer 1 Byte Contains index to the identifier of the 
device to be activated 


INT_PROTOCOL Binary 3 bit Protocol of device to be activated 


000b: Use NFC-DEP 
001b: Use ISO-DEP 
010b: Use Type 1 Tag Platform 
011b: Use Type 2 Tag Platform 
100b: Use Type 3 Tag Platform 


NOTE Use of Type 4 Tag Platform is covered by use of ISO-DEP. 


The data requested from the Greedy Collection is listed in Table 18: 


NFC Activity Specification 
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Table 18: Device Activation Activity — Input from Greedy Collection 


Name Format Size Description 
GRE SEL RES[] array of Byte | variable | Response of each identified device. 
Sequences Each element contains a SEL. RES 


Response from an NFC-A device. 


GRE SENSB RES[] array of Byte | variable | Response of each identified device. 


Sequences Each element contains a Response to an 
ALLB REQ or SENSB REQ Command 
from an NFC-B device. 


GRE SENSF RES[] array of Byte | variable | Response of each identified device. 


Sequences Each element contains a Response to an 
SENSF REQ Command from an NFC-F 
device. 


9.4.2  Post-conditions 


The Output Parameters returned to the Resolution Process are listed in Table 19: 


Table 19: Device Activation Activity - Output Parameters 


Name Format Size Description 

INT INDEX Integer 1 Byte Index to the identifier of the device 
activated 

CON BITR NFC DEP Integer 1 Byte Current Bitrate in case of NFC DEP 
activation: 


- 0: maintain bit rate 
- 1:106 kbps 
- 2:212 kbps 
- 3:424 kbps 


The data returned to the Greedy Collection is listed in Table 20: 


Table 20: Device Activation Activity — Output into Greedy Collection 


Name Format Size Description 
GRE ATR hexadecimal | > 17 Bytes | ATR, RES Response of device activated 
GRE RATS hexadecimal | 22 Bytes | RATS Response of device activated 


GRE. ATTRIB hexadecimal | > 1 Byte ATTRIB Response of device activated 
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NOTE There is no Greedy Collection for the Type 1 Tag Platform or Type 2 Tag Platform: 


NOTE For the Type 1 Tag Platform, the result of the RID Command is captured in the 
NFCID, as part of the Collision Resolution Activity. 


NOTE For the Type 2 Tag Platform, the outcome of the device activation (by means of a 
Valid READ or WRITE Command) is part of the Data Exchange Activity. 
9.4.3 Flow Chart (Normative) 


The Device Activation Activity to be performed depends on the value of the INT_TECH_SEL 
parameter and is defined in the normative Figure 10. 


dD 


Figure 10: Device Activation Activity (Sheet 1, Entry) - Normative Flow Chart 


9.4.4 Flow Chart and Requirements for NFC-A 


The purpose of the NFC-A-related part of the Device Activation Activity is to activate an NFC 
Forum Device within range that has activated support for NFC-A Technology (subset). 
Depending on the outcome of the Resolution Process of the previous Activity, the device to be 
activated supports NFC-DEP Protocol, Type 4A Tag Platform, Type 2 Tag Platform, or 

Type 1 Tag Platform. 


Figure 11 illustrates the NFC-DEP Protocol (NFC-A), Type 4A Tag Platform, 
Type 2 Tag Platform, and Type 1 Tag Platform related parts of the Activation Activity. 


NOTE There is no specific action for the Type 1 Tag Platform because this platform is 
activated implicitly upon completion of the NFC-A Collision Resolution Activity. 
For the same reason, there is no specific action for the Type 2 Tag Platform, unless it 
is in the SLEEP. A Sub-state. 
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Figure 11: Device Activation Activity (Sheet 2, Connector DA_1, NFC-DEP (NFC-A), Type 1, 


NFC Activity Specification 


2 6. 4A Tag Platform) — Flow Chart 


Page 78 


Poll Mode — Activities 


Symbols in this section refer to corresponding symbols in Figure 11. 


Requirements 28: Device Activation Activity - NFC-DEP (NFC-A), Type 1, 2, & 4A Tag 


Poll Mode 


9.4.4.1 


9.4.4.2 


9.4.4.3 


9.4.4.4 


9.4.4.5 


9.4.4.6 


9.4.4.7 


9.4.4.8 


Platform 


Symbol 0: 


If INT_PROTOCOL is equal to 010b, then the NFC Forum Device MUST conclude 
the Activation Activity. 


Symbol 1: 


If INT_NFCIDX_SLEEP[INT_INDEX] is equal to 1b (i.e., the device is in SLEEP_A 
Sub-state), then the NFC Forum Device MUST proceed to Symbol 2. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 10. 
Symbol 2: 

The NFC Forum Device MUST send an ALL. REQ Command. 
Symbol 3: 


If the SENS_RES indicates a single size NFCID1, then the NFC Forum Device 
MUST proceed to Symbol 5. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 4. 
Symbol 4: 


If INT_NFCIDX [INT_INDEX] indicates a double- or triple-size NFCID1, then the 
NFC Forum Device MUST first select cascade level 1 by sending a SEL_REQ 
Command with SEL_CMD = 93h and NFCID1 CL1, before continuing with cascade 
level 2. 


The NFC Forum Device MUST proceed to Symbol 6. 
Symbol 5: 


The NFC Forum Device MUST send a SEL_REQ Command with SEL_CMD = 93h 
and NFCID1 CL1 (of INT_NFCIDX [INT_INDEX]). 


Symbol 6: 


If INT NFCIDX[INT INDEX] indicates a double-size NFCID1, then the NFC 
Forum Device MUST proceed to Symbol 7. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 8. 
Symbol 7: 


The NFC Forum Device MUST send a SEL_REQ Command with SEL_CMD = 95h 
and NFCID1 CL2 (of INT NFCIDX [INT INDEX ]). 


The NFC Forum Device MUST proceed to Symbol 10. 
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9.4.4.10 


9.4.4.11 


9.4.4.12 


9.4.4.13 


9.4.4.14 
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Symbol 8: 


If INT_NFCIDX[INT_INDEX] indicates a triple-size NFCID1, then the NFC Forum 
Device MUST first select cascade level 2 by sending a SEL_REQ Command with 
SEL_CMD= 95h and NFCID1 CL2, before continuing with cascade level 3. Refer to 
[DIGITAL] for SENS_RES coding. 


Symbol 9: 


The NFC Forum Device MUST send a SEL REQ Command with SEL_CMD = 97h 
and NFCID1 CL3 (of INT NFCIDX [INT_INDEX]). 


Symbol 10: 


If INT_PROTOCOL is equal to 001b, then the NFC Forum Device MUST proceed to 
Symbol 11. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 12. 
Symbol 11: 


The NFC Forum Device MUST send a RATS Command as specified in [DIGITAL], 
containing the CON_RATS. The NFC Forum Device MUST handle the RATS 
Response as specified in [DIGITAL]. If a Valid RATS Response is received, the 
NFC Forum Device MUST store the RATS Response to GRE_RATS and it MUST 
conclude the NFC-A Activation Activity. 


Symbol 12: 


If INT_PROTOCOL is equal to 011b, then the NFC Forum Device MUST conclude 
the NFC-A Activation Activity. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 13. 
Symbol 13: 


The NFC Forum Device MUST send an ATR_REQ Command as specified in 
[DIGITAL], containing the identifier INT_NFCIDX [INT_INDEX]. The NFC Forum 
Device MUST handle the ATR_RES Response as specified in [DIGITAL]. If a Valid 
ATR_RES Response is received, the NFC Forum Device MUST 


e Set INT_NFCIDX_SLEEP[INT_INDEX] equal to Ob 
e Store the ATR_RES Response to GRE_ATR 
e Conclude the NFC-A Activation Activity 


NFC Activity Specification Page 80 


Poll Mode 


9.4.4.15 


Poll Mode — Activities 


Symbol 14: 


The NFC Forum Device MUST proceed to Symbol 15 if the following conditions 
apply: 

e PSL_ REQ is supported 

e CON BITR NFC DEP is equal to or larger than 2 


e The device identified by INT INDEX is the only device that the NFC Forum 
Device activates during execution of the active Profile 


Otherwise, the NFC Forum Device MUST conclude the NFC-A Activation Activity. 


The NFC Forum Device MAY also proceed to Symbol 15 if it wants to change the Length 
Reduction Values by using the FSL parameter of PSL_REQ as defined in [DIGITAL]. 


9.4.4.16 


NOTE 


NOTE 


Symbol 15: 
The NFC Forum Device MUST send a PSL. REQ. 


e If CON BITR NFC DEP is equal to 2, then the NFC Forum Device MUST set 
DSI equal to 001b. 


e If CON BITR NFC DEP is equal to or larger than 3, then the NFC Forum 
Device MUST set DSI equal to 010b. 


The PSL. REQ Command MUST be coded as specified in [DIGITAL ]. 


The NFC Forum Device MUST handle the PSL_REQ Response as specified in 
[DIGITAL]. 


If a Valid PSL_RES Response is received, the NFC Forum Device MUST: 


e Set CON_BITR_NFC_DEP according to the Bitrate specified by the DSI 
parameter of PSL_REQ 


e Conclude the NFC-A Activation Activity 


For activation of a Type 2 Tag Platform, the NFC Forum Device send a Valid Read 
or Write Command in compliance with the Type 2 Tag Platform as specified in 
[DIGITAL], handles the Response as specified in [DIGITAL], and concludes 
NFC-A Device Activation Activity. 


If DSI has been set to 001 or 010b and a valid PSL_RES Response has been 
received, the further communication uses NFC-F technology. 


9.4.5 Flow Chart and Requirements for NFC-B 


The purpose of the NFC-B Device Activation Activity is to activate an NFC Forum Device 
within range that has activated support for the Type 4B Tag Platform. 


Figure 12 illustrates the Type 4B Tag Platform related part of the Activation Activity. 
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Figure 12: Device Activation Activity (Sheet 3, Connector DA_2, Type 4B Tag Platform) — 
Flow Chart 


Symbols in this section refer to corresponding symbols in Figure 12. 
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Requirements 29: Device Activation Activity — Type 4B Tag Platform 


Symbol 0: 


If INT NFCIDX SLEEP[INT INDEX] is equal to 1b (i.e. the device is in SLEEP B 
Sub-state), then the NFC Forum Device MUST proceed to Symbol 1. 


Otherwise, the NFC Forum Device MUST proceed to Symbol 3. 
Symbol 1: 


The NFC Forum Device MUST send an ALLB. REQ Command as specified in 
[DIGITAL]. 


Symbol 2: 
The NFC Forum Device MUST set INT NFCIDX, SLEEP[0:n] equal to Ob 
Symbol 3: 


The NFC Forum Device MUST send an ATTRIB Command as specified in 
[DIGITAL], containing the NFCIDO included in INT_NFCIDX. If a Valid ATTRIB 
Response is received, the NFC Forum Device MUST store the ATTRIB Response to 
GRE_ATTRIB and it MUST conclude the NFC-B Activation Activity. Refer to 
[DIGITAL] for the definition of the ATTRIB Command and Response. 


9.4.6 Flow Chart and Requirements for NFC-F 


The purpose of the NFC-F Device Activation Activity is to activate an NFC Forum Device within 
range that has activated support for NFC-F Technology (subset). Such devices(?) may support 
NFC-DEP Protocol or Type 3 Tag Platform. 


Figure 13 illustrates the NFC-DEP Protocol (NFC-F) and Type 3 Tag Platform part of the 
Activation Activity. 


NOTE 


There is no specific action for the Type 3 Tag Platform as this platform is activated 
implicitly upon completion of the NFC-F Collision Resolution Activity. 


NFC Activity Specification Page 83 


INT_PROTOCOL 


= 100b ? 


ATR_REQ 


Send 
PSL REQ? 


PSL_REQ 


Poll Mode — Activities 


Figure 13: Device Activation Activity (Sheet 4, Connector DA_3, NFC-DEP (NFC-F)) — Flow 


Chart 


Symbols in this section refer to corresponding symbols in Figure 13. 
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9.4.6.2 


9.4.6.3 
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Requirements 30: Device Activation Activity - NFC-DEP (NFC-F) 


Symbol 0: 


If INT_PROTOCOL is equal to 100b, then the NFC Forum Device MUST conclude 
the Activation Activity. 


Symbol 1: 


The NFC Forum Device MUST send an ATR_REQ Command as specified in 
[DIGITAL], containing the identifier included in INT_NFCIDX. The NFC Forum 
Device MUST handle the ATR_RES Response as specified in [DIGITAL]. If a Valid 
ATR_RES Response is received, the NFC Forum Device MUST store the ATR_RES 
Response to GRE_ATR. 


Symbol 2: 

The NFC Forum Device MUST proceed to Symbol 3 if the following conditions 
apply 

e PSL_REQ/RES is supported 


e The Bitrate specified by CON_BITR_NFC_DEP is different that the current Bit 
rate 


e The device identified by INT_INDEX is the only device that the NFC Forum 
Device activates during execution of the active Profile 


Otherwise, the NFC Forum Device MUST conclude the NFC-F Activation Activity. 


The NFC Forum Device MAY also proceed to Symbol 3 if it wants to change the Length 
Reduction Values by using the FSL parameter of PSL_REQ as defined in [DIGITAL]. 


9.4.6.4 


NOTE 


Symbol 3: 
The NFC Forum Device MUST send a PSL_ REQ. 


e If CON_BITR_NFC_DEP is equal to 1, then the NFC Forum Device MUST set 
DSI equal to 000b. 


e If CON BITR. NFC DEP is equal to 2, then the NFC Forum Device MUST set 
DSI equal to 001b. 


e If CON BITR, NFC DEP is equal to or larger than 3, then the NFC Forum 
Device MUST set DSI equal to 010b. 


The PSL. REQ Command MUST be coded as specified in [DIGITAL ]. 


The NFC Forum Device MUST handle the PSL_REQ Response as specified in 
[DIGITAL]. 


If a Valid PSL_RES Response is received, the NFC Forum Device MUST: 


e Set CON_BITR_NFC_DEP according to the Bitrate specified by the DSI 
parameter in PSL_REQ 


e Conclude the NFC-F Activation Activity 


If DSI has been set to 000 and a valid PSL_RES Response has been received, the 
further communication uses NFC-A technology. 
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9.5 Data Exchange Activity 


This section describes the Data Exchange Activity. 


9.5.1  Pre-conditions 
There are no Configuration Parameters defined for this Activity. 


The Input Parameters for the Device Activation Activity are listed in Table 21: 
Table 21: Data Exchange Activity — Input Parameters 


Name Format Size Description 


INT_INDEX Integer 1 Byte Index to the identifier of device to 
exchange data with. 


INT PROTOCOL Binary 3 bit Protocol of device to exchange data with: 
- 000b: Use NFC-DEP 
- 001b: Use ISO-DEP 
- 010b: Use Type 1 Tag Platform 
- 011b: Use Type 2 Tag Platform 
- 100b: Use Type 3 Tag Platform 


NOTE Use of Type 4 Tag Platform is covered by use of ISO-DEP. 


The data requested from the Greedy Collection is listed in Table 22: 


Table 22: Device Activation Activity — Input from Greedy Collection 


Name Format Size Description 

GRE ATR hexadecimal | > 17 Bytes | ATR, RES Response of device activated 
GRE RATS hexadecimal | 22 Bytes | RATS Response of device activated 
GRE. ATTRIB hexadecimal | > 1 Byte ATTRIB Response of device activated 


9.5.2  Post-conditions 


The Output Parameters returned to the Resolution Process are listed in Table 23: 


Table 23: Data Exchange Activity — Output Parameters 


Description 


INT INDEX Integer 1 Byte Index to the identifier of the active 
device 


There is no data returned to the Greedy Collection by this Activity. 
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9.5.3 Flow Chart (Normative) 


The Data Exchange Activity to be performed depends on the value of the INT_PROTOCOL 
parameter and is defined in the normative Figure 14. 


LD 


NFC-DEP 
Data Exchange 


ISO-DEP 
Data Exchange 


Type 1 Tag 
Data Exchange 


Type 2 Tag 
Data Exchange 


Type 3 Tag 
Data Exchange 


Figure 14: Data Exchange Activity (Sheet 1, entry) - Normative Flow Chart 


9.5.4 Flow Chart and Requirements for NFC-DEP 


The purpose of the NFC-DEP Data Exchange Activity is to exchange data with an NFC Forum 
Device within range, communicating over NFC-DEP. 


Figure 15 illustrates the NFC-DEP-related part of the Data Exchange Activity. 
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EE 
DEP REQ 


continue data 
exchange ? 


Figure 15: Data Exchange Activity (Sheet 2, connector DE 1, NFC-DEP) - Flow Chart 
Symbols in this section refer to corresponding symbols in Figure 15. 


Requirements 31: Data Exchange Activity - NFC-DEP 
Poll Mode 


9.5.4.1 Symbol 1, Symbol 2: 


As long as data exchange continues, as controlled by the adjacent upper layer, the 
NFC Forum Device MUST send a DEP. REQ Command and it MUST wait for the 
DEP RES Response afterward, as specified in [DIGITAL]. 


9.5.5 Flow Chart and Requirements for ISO-DEP 


The purpose of the ISO-DEP Data Exchange Activity is to exchange data with an NFC Forum 
Device within range, communicating over ISO-DEP . 


Figure 16 illustrates the ISO-DEP-related part of the Data Exchange Activity. 


NOTE The Flow Chart and Requirements in this section also include the 
Type 4 Tag Platform as specified in [DIGITAL] and [TATOP]. 
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send command 


Figure 16: Data Exchange Activity (Sheet 3, Connector DE_2, ISO-DEP) — Flow Chart 


Symbols in this section refer to corresponding symbols in Figure 16. 
Requirements 32: Data Exchange Activity — ISO-DEP 
Poll Mode 


9.5.5.1 Symbol 1, Symbol 2: 


As long as data exchange continues, as controlled by the adjacent upper layer, the 
NFC Forum Device MUST send Commands and receive Responses as specified in 
[DIGITAL] for ISO-DEP. 
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9.5.6 Flow Chart and Requirements for Type 1 Tag Platform 


The purpose of the Type 1 Tag Platform Data Exchange Activity is to exchange data with an 
NFC Forum Device within range that has activated support for the Type 1 Tag Platform. 


Figure 17 illustrates the Type 1 Tag Platform-related part of the Data Exchange Activity. 


send command 


continue data 
exchange ? 


Figure 17: Data Exchange Activity (Sheet 4, Connector DE_3, Type 1 Tag Platform) — Flow 
Chart 


Symbols in this section refer to corresponding symbols in Figure 17. 


Requirements 33: Data Exchange Activity — Type 1 Tag Platform 
Poll Mode 


9.5.6.1 Symbol 1, Symbol 2: 


As long as data exchange continues, as controlled by the adjacent upper layer, the 
NFC Forum Device MUST send Commands and receive Responses as specified for 
the Type 1 Tag Platform in [DIGITAL] and [T1TOP]. 


The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the 
Type 1 Tag. 


9.5.7 Flow Chart and Requirements for Type 2 Tag Platform 


The purpose of the Type 2 Tag Platform Data Exchange Activity is to exchange data with an 
NFC Forum Device within range that has activated support for the Type 2 Tag Platform. 


Figure 18 illustrates the Type 2 Tag Platform-related part of the Data Exchange Activity. 
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send command 


Figure 18: Data Exchange Activity (Sheet 5, connector DE_4, Type 2 Tag Platform) — Flow 
Chart 


Symbols in this section refer to corresponding symbols in Figure 18. 


Requirements 34: Data Exchange Activity — Type 2 Tag Platform 
Poll Mode 


9.5.7.1 Symbol 1, Symbol 2: 


As long as data exchange continues, as controlled by the adjacent upper layer, the 
NFC Forum Device MUST send Commands and receive Responses as specified for 
the Type 2 Tag Platform in [DIGITAL] and [T2TOP]. 


The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the 
Type 2 Tag. 
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9.5.8 Flow Chart and Requirements for Type 3 Tag Platform 


The purpose of the Type 3 Tag Platform Data Exchange Activity is to exchange data with an 
NFC Forum Device within range that has activated support for the Type 3 Tag Platform. 


Figure 19 illustrates the Type 3 Tag Platform related part of the Data Exchange Activity. 


send command 


Continue data 


Figure 19: Data Exchange Activity (Sheet 6, connector DE_5, Type 3 Tag Platform) — Flow 
Chart 


Symbols in this section refer to corresponding symbols in Figure 19. 


Requirements 35: Data Exchange Activity — Type 3 Tag Platform 
Poll Mode 


9.5.8.1 Symbol 1, Symbol 2: 


As long as data exchange continues, as controlled by the adjacent upper layer, the 
NFC Forum Device MUST send Commands and receive Responses as specified for 
the Type 3 Tag Platform in [DIGITAL] and [T3TOP]. 


The NFC Forum Device MAY send Commands and receive Responses that are proprietary for the 
Type 3 Tag. 


9.5.9 Flow Chart and Requirements for Type 3 Tag Platform selection 


To select a Type 3 Tag Platform with a specific system code, the NFC Forum Device in Poll 
Mode needs to send a SENSF_REQ Command with the corresponding parameter settings. This 
includes the selection of Type 3 Tag Platforms that are NDEF enabled. 


Figure 20 illustrates the Type 3 Tag Platform Selection flow chart. 
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SENSF_REQ 


Figure 20: Type 3 Tag Platform Selection — Flow Chart 
Symbols in this section refer to corresponding symbols in Figure 20. 


Requirements 36: Type 3 Tag Selection 
Poll Mode 


9.5.9.1 Symbol 1: 


If the NFC Forum Device needs to select a specific Type 3 Tag Platform, the NFC 
Forum Device MUST send a SENSF_REQ Command with the parameter values set 
by the adjacent upper layer. 


To select an NDEF-enabled Type 3 Tag Platform, the NFC Forum Device MUST set 
SC to 12FCh and RC to 00h. 


The NFC Forum Device MUST handle the SENSF_RES Response as specified in 
[DIGITAL]. 
If Valid SENSF_RES Responses are received, the NFC F'orum Device MAY use the data 
contained in a SENSF_RES Responses (e.g. NFCID2) during the further communication in the 
Data Exchange Activity instead of the data associated to INT_INDEX. 
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9.6 Device Deactivation Activity 


This section describes the Device Deactivation Activity. 


9.6.1  Pre-conditions 
There are no Configuration Parameters defined for this Activity. 


The Parameters requested from Resolution for the Device Deactivation Activity are listed in 
Table 24: 


Table 24: Device Deactivation Activity — Input Parameters 


Name Format Size Description 

INT_INDEX integer 1 Byte Index to the identifier of device to be 
deactivated 

INT PROTOCOL _ | binary 3 bit Protocol to be deactivated: 


- 000b: Using NFC-DEP 

- 001b: Using ISO-DEP 

- 010b: Using Type 1 Tag Platform 
protocol 

- 011b: Using Type 2 Tag Platform 
protocol 

- 100b: Using Type 3 Tag Platform 
protocol 


There is no data needed from the Greedy Collection for this Activity. 


9.6.2  Post-conditions 


The Output Parameters returned to the Resolution Process are listed in Table 25: 


Table 25: Device Deactivation Activity - Output Parameters 


Format Size Description 
INT INDEX Integer 1 Byte Index to the identifier of the device 
deactivated 


There is no data returned to the Greedy Collection by this Activity. 


9.6.3 Flow Chart (Normative) 


The Device Deactivation Activity to be performed depends on the value of the INT PROTOCOL 
parameter and is defined in the normative Figure 21. 
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Deactivation 
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Deactivation 


Yes 


Type 2 Tag 
Deactivation 


Yes 


Figure 21: Device Deactivation Activity (Sheet 1, Entry) - Normative Flow Chart 


9.6.4 Flow Chart and Requirements for NFC-DEP 


The purpose of the NFC-DEP Device Deactivation Activity is to deactivate an NFC Forum 
Device within range, communicating over NFC-DEP. 


Figure 22 illustrates the NFC-DEP-related part of the Deactivation Activity. 
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INT_NFCIDX_SLEEP 


Figure 22: Deactivation Activity (Sheet 2, Connector DD_1, NFC-DEP) — Flow Chart 
Symbols in this section refer to corresponding symbols in Figure 22. 


Requirements 37: Deactivation Activity - NFC-DEP 
Poll Mode 


9.6.4.1 Symbol 1: 


The NFC Forum Device MUST send a RLS REQ Command or DSL. REQ as 
specified in [DIGITAL]. 


9.6.4.2 Symbol 2: 


Upon receipt of a RLS. RES, the NFC Forum Device MUST set 
INT NFCIDX SLEEP[INT INDEX] equal to Ob. 


For NFC-A, upon receipt of a DSL. RES, the NFC Forum Device MUST set 
INT NFCIDX SLEEP[INT INDEX] equal to 1b. 


For NFC-F, upon receipt of a DSL. RES, the NFC Forum Device MUST set 
INT NFCIDX SLEEP[INT INDEX] equal to Ob. 


9.6.5 Flow Chart and Requirements for ISO-DEP 


The purpose of the ISO-DEP Device Deactivation Activity is to deactivate an NFC Forum Device 
within range, communicating over ISO-DEP. 


Figure 23 illustrates the ISO-DEP-related part of the Deactivation Activity. 
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Set 
INT NFCIDX SLEEP 


Figure 23: Deactivation Activity (Sheet 3, connector DD 2, ISO-DEP) - Flow Chart 
Symbols in this section refer to corresponding symbols in Figure 23. 


Requirements 38: Deactivation Activity — ISO-DEP 
Poll Mode 


9.6.5.1 Symbol 1: 


The NFC Forum Device MUST send an S(DESELECT) Request, as specified in 
[DIGITAL]. 


9.6.5.2 Symbol 2: 


Upon receipt of the S(DESELECT) Response, the NFC Forum Device MUST set 
INT_NFCIDX_SLEEP[INT_INDEX] is equal to 1b. 


9.6.6 Flow Chart and Requirements for Type 1 Tag Platform 


For a Type 1 Tag Platform, there is no particular Device Deactivation Activity. 


9.6.7 Flow Chart and Requirements for Type 2 Tag Platform 


The purpose of the Type 2 Tag Platform Deactivation Activity is to deactivate a 
Type 2 Tag Platform within range. 


Figure 24 illustrates the Type 2 Tag Platform-related part of the Deactivation Activity. 
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SLP_REQ 


Figure 24: Deactivation Activity (Sheet 4, connector DD_3, Type 2 Tag Platform) — Flow 
Chart 


Symbols in this section refer to corresponding symbols in Figure 24. 
Requirements 39: Deactivation Activity — Type 2 Tag Platform 
Poll Mode 


9.6.7.1 Symbol 1: 


The NFC Forum Device MUST send a SLP _REQ Command, as specified in 
[DIGITAL]. 


9.6.8 Flow Chart and Requirements for Type 3 Tag Platform 


For a Type 3 Tag Platform, there is no particular Device Deactivation Activity. 
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10 Poll Mode — Profiles 


A Profile defines a sequence of Activities to be performed by the NFC Forum Device. This 
sequence is not necessarily fixed, but can develop based on the outcome of the Resolution 
Processes. 


A Profile definition consists of: 
e The Configuration Parameters values of the Activities used in the Profile 
e The Resolution Process of the Profile 


A Resolution Process consists of an algorithm that is controlled by the adjacent upper layer and 
determines the next Activity to call, depending on the outcome of the previous Activity. For each 
possible Activity to call next, the Resolution Process provides the necessary input Parameters. 


The adjacent upper layer has the freedom to execute profiles sequentially in any order and it may 
also freely switch between Profiles in Poll Mode and Listen Mode. 


(M) 


» 
yes no 
Poll Mode? 
Y 
| | Profile LISTEN MODE 
Resolution process 
ml 
yes 
Continue? 


Figure 25: Sequential execution of profiles 


For the purpose of this document, only a limited set of Profiles is defined. For these definitions, 
the focus is on realizing the NFC Forum Communication use cases. These use cases are covered 
through three Profiles: P2P, NDEF, and P2PNDEF. Each Profile is defined to run without user 
intervention during the communication process. 


NOTE User intervention may be required prior to the communication process to set up the 
Profiles. 
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10.1 Greedy Collection Information 


For some decisions in the resolution processes, information contained in the Greedy Collection 
must be evaluated. Table 26 describes what information in the Greedy Collection must be used 


for a specific decision. 


Table 26: Greedy Collection Information Required for Resolution Processes 


Decision Greedy Collection More 
Information 
Is NFC-A device capable | Determined by b6 and b7 of the SEL. RES of | [DIGITAL] 


Type 2 Tag Platform? 


the device, which is contained in 
GRE_SEL_RES[]. 


of NFC-DEP? the device, which is contained in Section 4.8.2 
GRE_SEL_RES[]. 
Is NFC-F device capable | Determined by Byte 1 and Byte 2 of NFCID2 | [DIGITAL] 
of NFC-DEP? field in SENSF_RES. SENSF_RES of the Section 6.6.2 
device, which is contained in 
GRE POLL FT] (after Technology 
Detection) or GRE. SENSF RES[] (after 
Collision Resolution). 
Does device support Determined by b1—b5 of SENS. RES of the [DIGITAL] 
Type 1 Tag Platform? device, which is contained in Section 4.6.3 
GRE POLL A[]. 
Does device support Determined by b6 and b7 of the SEL. RES of | [DIGITAL] 


Section 4.8.2 


Does device support 
Type 3 Tag Platform? 


Determined by Byte 1 and Byte 2 of NFCID2 
field in SENSF RES. SENSF_RES of the 
device, which is contained in 

GRE POLL FT] (after Technology 
Detection) or GRE. SENSF RES[] (after 
Collision Resolution). 


[DIGITAL] 
Section 6.6.2 


Does NFC-A device 
support ISO-DEP? 


Determined by b6 and b7 of SEL. RES of the 
device, which is contained in 
GRE SEL RES[]. 


[DIGITAL] 
Section 4.8.2 


Does NFC-B device 
support ISO-DEP? 


Determined by b1 of Protocol Type field of 
SENSB RES, which is contained in 

GRE POLL B[] (after Technology 
Detection) or GRE SENSB RES[] (after 
Collision Resolution). 


[DIGITAL] 
Section 5.6.2 
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10.2 P2P Poll Profile 


The P2P Poll Profile is developed to establish a communication with another NFC Forum device 
using the NFC-DEP protocol. To enable a high data throughput for LLCP, the Profile uses the 
highest bit rate supported by the NFC Forum Device in Listen Mode for NFC-DEP. The Profile 
ends without establishing a communication if multiple NFC-DEP capable devices are found. 


10.2.1 Configuration Parameters 
For this Profile, the Technology Detection uses a speed of 424kbit/s for NFC-F. 
The Configuration Parameters for the P2P Poll Profile are listed in Table 27: 


Table 27: P2P Poll Profile Configuration Parameters 


Parameter P2P 
CON_POLL_A Ob 
CON_POLL_B Ob 
CON_POLL_F 1b 
CON_POLL_P Ob 
CON_BAIL_OUT_A Ob 
CON_BAIL_OUT_B Ob 
CON_DEVICES_LIMIT 01h 
CON_ADV_FEAT Ob 

CON_ATR As defined in [DIGITAL] 
CON_GB LLCP Parameters 
CON_RATS n.a. 
CON_ATTRIB n.a. 

CON BITR, NFC DEP 2 


10.2.2 Resolution Process 
The resolution process of the P2P Poll Profile is defined by Figure 26. 


! Start at 424 and stay at this bit rate 
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y 
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y 
NFCDEPDevices := 0 
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no 
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NFCIDX INT_PROTOCOL := 000b | 
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Y 
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Sequence of commands 
NFCDEPDevices * 1 according to NFC-DEP 
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y Y 


Device Deactivation 


y 


os) 


capability? 


FCDEPDevices > 17 


Figure 26: P2P Poll Profile Resolution Process 
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10.3 NDEF Poll Profile 


The purpose of the NDEF Poll Profile is to access the NDEF data on a tag. The Profile first 
searches for an NDEF-capable tag and, if there is exactly one, it establishes a communication 
with it. Depending on the tag type, detecting NDEF on a tag may require that a data exchange 
Activity is performed with the device and READ Commands are issued according to the 
corresponding Type Tag Platform Operations specification. The Profile ends without establishing 
a communication if multiple NDEF-capable tags are detected. 


10.3.1 Configuration Parameters 
The Configuration Parameters for the NDEF Poll Profile are listed in Table 28: 


Table 28: NDEF Poll Profile Configuration Parameters 


Parameter NDEF 

CON POLL A 1b 

CON POLL B 1b 

CON POLL F 1b 

CON POLL P Ob 

CON_BAIL_OUT_A Ob 

CON_BAIL_OUT_B Ob 
CON_DEVICES_LIMIT 04h 

CON_ADV_FEAT Ob 

CON_ATR n.a 

CON_GB None 

CON_RATS As defined in [DIGITAL] 
CON_ATTRIB As defined in [DIGITAL] 
CON_BITR_NFC_DEP 0 


10.3.2 Resolution Process 
The resolution process of the NDEF Poll Profile is defined by Figure 27 and Figure 28. 
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i Device Deactivation can be skipped in case NDEF was detected, no other NDEF and NFC-DEP capable devices have been detected before and the current device is 
the last device to be investigated. 


Figure 27: NDEF Poll Profile Resolution Process — Sheet 1 
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Figure 28: NDEF Poll Profile Resolution Process - Sheet 2 
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10.4 P2PNDEF Poll Profile 


The P2PNDEF Profile searches for NDEF tags and NFC-DEP-capable devices. If exactly one 
device is identified, the Profile starts a communication session with this device. If the identified 
device is an NDEF-capable tag, the communication session allows the device to access NDEF on 
the tag. If the identified device is an NFC Forum Device, the communication session establishes 
an NFC-DEP communication between the devices. The Profile ends without establishing a 
communication if multiple NFC Forum devices or NFC Forum tags are detected. 


10.4.1 Configuration Parameters 
The Configuration Parameters for the P2PNDEF Poll Profile are listed in Table 29: 


Table 29: P2PNDEF Poll Profile Configuration Parameters 


Parameter NDEF 
CON_POLL_A 1b 
CON_POLL_B 1b 
CON_POLL_F 1b 
CON_POLL_P Ob 
CON_BAIL_OUT_A Ob 
CON_BAIL_OUT_B Ob 
CON_DEVICES_LIMIT 04h 
CON_ADV_FEAT Ob 
CON_ATR As defined in 
[DIGITAL] 
CON_GB LLCP Parameters 
CON_RATS As defined in 
[DIGITAL] 
CON_ATTRIB As defined in 
[DIGITAL] 
CON_BITR_NFC_DEP 3 


10.4.2 Resolution Process 


The resolution process has been split into parts by using subroutines to improve readability. 
Figure 29 shows the main flow of the resolution process. The *FOUND [AJ|B|F] processing 
subroutines (as shown in Figure 30, Figure 31, and Figure 32) detect the number of NDEF- 
enabled tags and NFC-DEP targets for the corresponding technology. The “Device 
communication” subroutine, as shown in Figure 33, handles the data exchange if a single 
communication partner has been identified. 


23 
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Figure 29: NDEFP2P Poll Profile Resolution Process — Main Flow 
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1 Device Deactivation can be skipped in case NDEF was detected, no other NDEF and NFC-DEP capable devices have been 
detected before and the current device is the last device to be investigated. 


Figure 30: NDEFP2P Poll Profile Resolution Process - FOUND A Processing 
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Figure 31: NDEFP2P Poll Profile Resolution Process - FOUND B Processing 
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Figure 32: NDEFP2P Poll Profile Resolution Process - FOUND F Processing 
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Figure 33: NDEFP2P Poll Profile Resolution Process — Device Communication 
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Figure 34: NDEFP2P Poll Profile Resolution Process - NFC-A Communication 


NFC Activity Specification 


Page 112 


Listen Mode — State Diagram (Informative) 


A. Listen Mode — State Diagram (Informative) 
Figure 35 shows a graphical representation of an NFC Forum Device in Listen Mode. 
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Figure 35: Listen Mode - State Diagram (Informative) 
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B. Values 


Throughout this document, symbols are used to identify the values of Parameters. The actual 
values of the Parameters are listed in Table 30. For some of the Parameters, a minimum and 
maximum value is defined. Other Parameters are defined by a single value. 


Values 


Parameters have a value for the NFC Forum Device in Poll Mode and for the NFC Forum Device 
in Listen Mode. Unless otherwise specified, the value for Poll Mode has to be used when the 
parameter is referenced in a Poll Mode requirement. The value for Listen Mode has to be used 


when referenced in a Listen Mode requirement. 


Table 30: Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Nominal Max 
trieLD_OFF 5.1 5.0 ms 
PTGTĄ 0.5 ms 
PTGTB 3.8 ms 
PTGTe 0.5 ms 
GTA 5.1 See [DIGITAL]. ms 
GTB 5.1 See [DIGITAL]. ms 
GTBr 15.3 See GT; in [DIGITAL]. ms 
GTrB 20.4 See GTr in [DIGITAL]. ms 
NFC Activity Specification Page 114 


Revision History 


C. Revision History 


The following table outlines the revision history of NFC Activity Specification. 


Table 31: Revision History 


Document Revision and Change Notice Supersedes 
Name Release Date 


NFC Activity Version 1.0, Technical 
Specification November 2010 | Specification 
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